I started using StandardGame as a base for my application and have a few questions:
What is the updateLock for? I can only see it being locked in the run method, then unlocked and locked again in the update method, all of which happens on the same thread. Is this field redundant or is it doing something I am missing?
StandardGame has a method for setting the uncaught exception handler:
public void setUncaughtExceptionHandler(UncaughtExceptionHandler exceptionHandler) {
this.exceptionHandler = exceptionHandler;
gameThread.setUncaughtExceptionHandler(this.exceptionHandler);
}
This throws a NullPointException if the game hasn't been started (gameThread==null). Easy enough to fix as the exception handler is applied when the thread is created.
updateLockis the lock that enables several tasks coming from different thread to be synchronized into the GL thread. This is required for the system to work!
Also, on your second point, I think you are right, in that this would be a desirable behavior, but you will have to wait for Darkfrog's answer on that one.
Looking at the source code I know it seems strange, but using game.lock() and game.unlock() it allows you to pause the update process at a "safe" place in order to do things to the scene-graph without worrying about thread-safety. When you call game.lock() it blocks until that thread gains a lock and then returns. This causes the game thread to be paused on the line where it unlocks (which opens it up to another thread that is waiting) and re-locks (which will block until the other thread releases its lock).
That's a good find. I have not been able to work on jME for a while so if another developer sees this and would be willing to apply it I would appreciate it.
1. Looking at the source code I know it seems strange, but using game.lock() and game.unlock() it allows you to pause the update process at a "safe" place in order to do things to the scene-graph without worrying about thread-safety. When you call game.lock() it blocks until that thread gains a lock and then returns. This causes the game thread to be paused on the line where it unlocks (which opens it up to another thread that is waiting) and re-locks (which will block until the other thread releases its lock).
OK I think I understand, and yeah it does look strange by reading the code. The idea is that if an external thread, outside my game loop, needs to update data on the scene graph, these methods allow me to do it safely. It's not used internally to the game loop. Understood, thanks for that. But why lock the game loop, why not synchronize access to the scene graph? I think you're saying that with this locking mechanism I can be sure that its locked in a "safe" during the loop (ie in between the unlock/lock calls in the update method). Now that I think about it, it makes sense.
darkfrog said:
2. That's a good find. I have not been able to work on jME for a while so if another developer sees this and would be willing to apply it I would appreciate it. :)
It was an easy find, I wanted to display something reasonable when classes or libs weren't found!
