# Program in a Program?
**URL:** https://discourse.processing.org/t/program-in-a-program/386
**Category:** Project Guidance
**Created:** [May 25, 2018, 10:18pm UTC](https://discourse.processing.org/t/program-in-a-program/386 "2018-05-25T22:18:14Z")
**Posts on this page:** 6
**Page:** 2
### Author:  [@neilcsmith](https://discourse.processing.org/u/neilcsmith)
#### Post date: [May 30, 2018, 9:57am UTC](https://discourse.processing.org/t/program-in-a-program/386/21 "2018-05-30T09:57:54Z")
> [@GoToLoop](#):
>
> AFAIK, Processing hasn’t been `synchronized` its stuff at least since Processing 1.5.1! 🤓
That was mostly meant as a joke! 😄 Although you could theoretically extend a renderer to did this.
> [@ag123](#):
>
> and about the threads, i think AWT or more correctly Swing still have something to do with the Event Dispatch Thread which is a java issue.
You were more correct with AWT actually! 😄 The EDT is part of AWT, and you can check if your code is running on it using `EventQueue.isDispatchThread()`. ~~This should mainly be in event callbacks~~. Neither the Java2D or JOGL renderers use this for `draw()`.
---
### Author:  [@GoToLoop](https://discourse.processing.org/u/GoToLoop)
#### Post date: [May 30, 2018, 11:04am UTC](https://discourse.processing.org/t/program-in-a-program/386/22 "2018-05-30T11:04:04Z")
> [@ag123](#):
>
> … I think AWT or more correctly Swing still have something to do with the Event Dispatch Thread which is a Java issue.
We can type in `println( Thread.currentThread() );` in order to find out the current Thread running a function: 😸
- [Is this a known bug? - Processing 2.x and 3.x Forum](https://Forum.Processing.org/two/discussion/24624/is-this-a-known-bug#Item_13)
- [push exceeding 32 use limit - Processing 2.x and 3.x Forum](https://Forum.Processing.org/two/discussion/15972/push-exceeding-32-use-limit#Item_12)
---
### Author:  [@ag123](https://discourse.processing.org/u/ag123)
#### Post date: [May 30, 2018, 3:42pm UTC](https://discourse.processing.org/t/program-in-a-program/386/23 "2018-05-30T15:42:39Z")
OT: about threads:
this would take it somewhat off topic, as i meddle more in java than processing itself.
i’ve tried things like rendering things in image buffers and using executor service to run them in different threads. [http://tutorials.jenkov.com/java-util-concurrent/executorservice.html](http://tutorials.jenkov.com/java-util-concurrent/executorservice.html)
after that i combine/blit them into the canvas like tiles when each thread of the executor service completes and return images to the main routine (this could be draw()). even on AWT/Swing that significantly speed up some heavy graphing/plotting work. this is especially observable (from waiting ~10 seconds to completing in a heartbeat) on the slower but multi-core cpus that’s prevalent on laptops, netbooks, tablets PCs these days.
i’d think similar strategies can be done in processing.
---
### Author:  [@neilcsmith](https://discourse.processing.org/u/neilcsmith)
#### Post date: [May 30, 2018, 3:56pm UTC](https://discourse.processing.org/t/program-in-a-program/386/24 "2018-05-30T15:56:53Z")
Yes, that’ll work if you’re CPU bound, and doing operations that Java2D can’t run on the GPU, so direct pixel stuff especially. But I would guess most people doing intensive graphical things are running one of the OpenGL renderers?! In which case they’re probably GPU bound and this approach wouldn’t help / would break.
Good to see you using ExecutorService - most attempts at threading around here are “interesting” 😄
---
### Author:  [@ag123](https://discourse.processing.org/u/ag123)
#### Post date: [May 30, 2018, 4:06pm UTC](https://discourse.processing.org/t/program-in-a-program/386/25 "2018-05-30T16:06:11Z")
one of those things i like about ExecutorService is that invokeAll().
it is basically first setting up a bunch of Callables put them in a Set and invokeAll().
this has the disadvantage that it would block and wait for all the threads to complete and results to return, but this could still be a lot faster if each thread/job takes about same amount of time to complete. But i’d say invokeAll() is very convenient compared to managing the threads separately.
for openGL i’m not too sure if separate sets of GLSL scripts may be generated in different threads and then bundled into a big script say when it gets collected up in draw(), then the whole script could be ‘pushed’ to the hardware to render. but i think there may still be bottlenecks with this approach
---
### Author:  [@ProcessingOrg](https://discourse.processing.org/u/ProcessingOrg)
#### Post date: [May 22, 2026, 11:54am UTC](https://discourse.processing.org/t/program-in-a-program/386/28 "2026-05-22T11:54:38Z")
[Previous page](https://discourse.processing.org/t/program-in-a-program/386.md?page=1)