Hi all,
I was just wondering if there is any easy way in JME to detect if we are not on the rendering thread. I’m seeing a data inconsistency that no matter how I trace through the code I can’t work out how it would happen - unless I’ve accidentally called something from the wrong thread…although I’ve also checked all the obvious places that could happen and not found anything!
If all else fails I guess I can record the identity of the render thread in app init and then check against that but I was wondering if there was a better way.
Thanks,
Z
You could set a threadLocal variable for yourself or make a Thread.currentThread() reference in simpleInit() to be able to compare.
Yes get your threads via Thread.currentthread and compare with that.
Bonus points: use assert instead of a if, as they are only active if you use -ea as vm argument and you dont need to remove them later for performance reasons
I used this in the past… Worked fine.
[java]
if (Thread.currentThread().getName().contains("LWJGL")) {
// do something
}
[/java]
Alternatively you can check whichever thread name you want or switch the name if you use Java 7.
[java] assert Thread.currentThread().getName().contains("LWJGL"): "Not in LWJGL thread";
[/java]
@madjack said:
I used this in the past... Worked fine.
[java]
if (Thread.currentThread().getName().contains("LWJGL")) {
// do something
}
[/java]
Alternatively you can check whichever thread name you want or switch the name if you use Java 7.
I shall create jme plugins that create a "LWJGL Helper Thread" to fool your check ;P
Edit: btw, why u guys don't know what thread u're on?
In theory I’m always on the LWJGL thread at the point these methods are called. However if I forgot to enqueue at some point (for example network message arrives and I process directly on the networking threads) then it could be called from the wrong thread.
I need to detect that immediately it happens rather than further down the line when a race condition causes an inconsistency somewhere.
@zarch said:
In theory I'm always on the LWJGL thread at the point these methods are called. However if I forgot to enqueue at some point (for example network message arrives and I process directly on the networking threads) then it could be called from the wrong thread.
I need to detect that immediately it happens rather than further down the line when a race condition causes an inconsistency somewhere.
Alright, as an assertion its great (maybe actually use assertions for that) but as a programming pattern it would really not be good.
Yeah, it’s an error check not part of standard program flow logic. That would just be weird. Using assertions means it won’t effect performance in release, but will help me catch problems before they happen in debugging.
(This isn’t code that’s called every frame either - it’s called when processing network messages etc).
1 Like
@normen said:
I shall create jme plugins that create a "LWJGL Helper Thread" to fool your check ;P
Edit: btw, why u guys don't know what thread u're on?
I shall not like you very much if you do! ;)
And, to answer the question, I used to do that because I was fiddling with the scene graph on a different thread using the same method. With the way above I was discriminating if the task was sent to a Future (etc) or directly via the opengl thread.
The good news is, I don't use that anymore but the method remained, just in case.