Possible to manually "start X" instead of -XstartOnFirstThread?

OpenGL Development
#1

Hello.

I’ve made this fancy-schmancy GLFW event handling system with LWJGL 3 that dedicates a thread to input processing while respecting all the threading limitations of GLFW (trust me, that was hard). I’d fire up a new thread and dedicate it to GLFW commands so that rendering/updating doesn’t affect the responsiveness of the window or input event recording precision. However, when running this code on Mac it’s broken since I need to use the -XstartOnFirstThread VM command… which breaks everything since I want to “start X” (whatever that means) on different thread than the main thread: the dedicated GLFW thread. This leads to the extremely awkward position where I need to do everything backwards, and dedicate the main thread to GLFW and transfer control of the entire game to a new thread instead. This is intrusive as fuck, reduces readability and has already caused hard-to-find bugs for us.

Is there any way of manually doing the equivalent of -XstartOnFirstThread but on a thread of our choosing?

#2

It’s Apple (specifically, the Cocoa API developers/designers) being a special snowflake, and AFAIK there’s nothing you can do about it.

Same problem occurs no matter what language you use. It’s just that most (native) languages don’t start on a new thread by default, so single-threaded applications aren’t affected.

#3

Why not move the GLFW stuff to start on the main thread, and the game run on a separate thread? ( That may take a ludicrous amount of time, depending on the game )

#4

That’s exactly what I’m doing right now, but it’s ugly. Forcing the user to move the entire game to a new thread and doing some seemingly arbitrary unintuitive calls is what I’m trying to avoid. The cleanest solution of this kind is to abstract the entire thing away and have the player give a “game interface” to an engine, which handles the thread hand-over. I don’t want to force the user to do this shit, and I don’t want to surprise them 6 months into development with having to do hacky shit like this to make it work on Apple.

I had a long chat session with Spasi over Skype, and got some more info on why this is required on Mac and how to work around it. The “cleanest” solution for the user is to create a small native C program which fires up a JVM using the Invocation API. It’d create a new thread for the application and call the application’s main() method, then start the GLFW event handling loop on the main thread. The Java code then just needs to realize that the event handling thread will be created externally.

I’d prefer this solution in the long run since I’d rather require a hack for getting the engine to run on Mac than have the user manually work around limitations of Mac to get anything at all to run.

#5

Just to make this clearer, or to be a complete pedant ;D

This has nothing to do with anything called “X”. -X just means this is a non-standard option for the JVM.

http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html

#6

Yeah, I realized that from Spasi’s explanation. It just forces the entire VM to start on the first thread of the process, which due to Mac’s stupid limitations is the only thread that can do UI stuff. Usually it’d dedicate the first thread to AWT/Swing just for this purpose. It’s just stupid.