I would like to open this topic for discussion since i run into a few issues that are not solvable without core modification.
The issue comes up when you are using engine methods that internally use TempVars.
As a common example, Ray intersection of BoundingVolumes. As they are nicely paralellizable in theory it does not work because of the TempVars… Or even worse, when using java 8 features like ParalellStreams you even loose control of the amount of Threads spawned and the error depend on the amount of cpu cores/threads, and the timing of course.
Another example is Light.intersectsFrustum, but here i can at least provide my own TempVars so its a solvable issue.
IMHO modifying TempVars.get() to use a ThreadLocal factory would solve the issues with a minimal change without having to touch lots of classes. But i am open to other ideas…
Wouldn’t this cause your parallel stream to create an indefinite amount of TempVars instances (virtually one per value), and thus defeat the purpose of TempVars?
Would increase the timing negating the value of tempvars. Could just remove them and get the same benefit I guess.
JME classes are not thread safe. That means they are not thread safe. ie: don’t use them, don’t call them, don’t query their values, etc. from more than one thread at a time. If the object is attached to the scene then “hands off”.
What if you are querying/intersecting that bounding volume while something else is changing its values? Same problem, same solution.
And actually, despite my performance comment… TempVars is already using a ThreadLocal.
Still, there are other reasons it is dangerous to try to use non-thread safe code from multiple threads. ThreadLocal is used in TempVars because it is a static singleton and otherwise all threads would share the same thread local stack… and that would be bad.