First question is directly related to JME…
When tasks are enqued in JME… say for adding/removing geometries from the scene, how many are handled per pass of the main applications loop? Is this a fixed number? Or? Is there a maximum limit?
Second question is related to the use of java.util.concurrent.ThreadPoolExecutor in a Control… sort of…
(This is hypothetical)
Lets say you were writing a control you plan on turning into a plugin for others and it required the use of a ThreadPoolExecutor. How does this work, considering it may be added to an existing multithreaded application that already makes use of a ThreadPoolExecutor? Is it best to require the ThreadPoolExecutor is passed in as a reference? Or?
(This is not)
How do you safely define the number for threads it will handle not knowing your target platform’s hardware?
Anyways… I’m sure I have a ton more questions that are as non-sensical. Maybe some others do as well?
@t0neg0d said:
First question is directly related to JME...
When tasks are enqued in JME... say for adding/removing geometries from the scene, how many are handled per pass of the main applications loop? Is this a fixed number? Or? Is there a maximum limit?
All of them. Queue 50 up and all 50 will run during the next update() pass.
@t0neg0d said:
Second question is related to the use of java.util.concurrent.ThreadPoolExecutor in a Control... sort of...
(This is hypothetical)
Lets say you were writing a control you plan on turning into a plugin for others and it required the use of a ThreadPoolExecutor. How does this work, considering it may be added to an existing multithreaded application that already makes use of a ThreadPoolExecutor? Is it best to require the ThreadPoolExecutor is passed in as a reference? Or?
Does it need to have its own executor or use a shared one? You might be happier setting up an app state to manage the executor and then pass that to the control during construction (or let the app state construct the control for you... or any number of ways to clean it up).
@t0neg0d said:
(This is not)
How do you safely define the number for threads it will handle not knowing your target platform's hardware?
You can scale it based on the number of CPUs. A lot of it depends on what the threads will be doing.
http://docs.oracle.com/javase/6/docs/api/java/lang/Runtime.html#availableProcessors()
I think I set my geometry builder thread count to 2 * CPUs with a max of 6 or something. I'd have to look it up. I could have also done cpu / 2 with a min of 2. Can't remember.
1 Like
t0neg0d said:
(This is hypothetical)
Lets say you were writing a control you plan on turning into a plugin for others and it required the use of a ThreadPoolExecutor. How does this work, considering it may be added to an existing multithreaded application that already makes use of a ThreadPoolExecutor? Is it best to require the ThreadPoolExecutor is passed in as a reference? Or?
Let me guess, you are thinking about what level of support do you want to offer at the API-level. Should "clients" of the API have to set up the executor or should the API take care of it? I'd say you want it passed as a reference and let the clients provide one.
Then if you really want a default set-up to make it easier to use you can always provide an "extended" control wrapping the real one.
1 Like