On Oct 12, 2008, at 2:25 PM, Michael Franz wrote:
On Oct 12, 2008, at 12:26 PM, Michael Franz wrote:
On Oct 11, 2008, at 6:14 PM, Michael Franz wrote:
Hi,
On Sun, Sep 7, 2008 at 9:22 PM, Landon Fuller
<landonf@plausiblelabs.com> wrote:
On Sep 7, 2008, at 1:08 PM, Michael Franz wrote:
I changed the startup to not pass the flag. I was running this from inside eclipse, but eclipse must somehow pass the option as it did not show up in the command.
-XstartOnFirstThread:
Soylatte by starts a Cocoa runloop on the first thread, and then run the JVM main() function again on a separate thread
Setting -XstartOnFirstThread has the same behavior on Mac OS X, in that Java is started directly on the first thread.
Reading through the code and finding a few bugs on primordial threads and this blog entry[1] , I wonder if -XstartOnFirstThread is really OS X specific (I assumed it was).
I was also reading through the Cocoa reference I have, my understanding is that it is possible to create a runloop on other threads, not just the first thread.
You can create runloops on other threads, but their sources will be setup by you. Only the runloop on Thread 0 receives keyboard and mouse events, which is why -XstartOnFirstThread is necessary when user-space code wants to pump the event loop. Otherwise, Thread 0 needs to be parked until it's time for the AWT to startup, and start running the show.
Is it possible to find Thread 0 from other threads?
I'm not sure what you mean by "find"? Like, with the pthread API? Once a runloop is pumping on it, most other API can deliver work to it via -performSelectorOnMainThread:, or other CFRunLoop API - but if user-space code never starts a runloop on Thread 0, those API's in AppKit, Carbon, etc will not work.
What I meant, is can thread 1 find thread 0 where find is obtain a reference to it. That is probably not necessary as you state work can be assigned to thread 0 from other threads.
What I see the current startup logic doing is creating the JVM in a new thread and waiting for that thread to die. If we need thread 0 to create the runloop, how does it know when the JVM has exited? I was thinking that maybe the jvm creation thread could send a message to the runloop that when it finishes. This would mean that there would be no need to -XstartOnFirstThread as thread 0 would always create the runloop.
Perhaps the SWT guys could chime in here, since their plans might be changing for SWT/Cocoa, but for the current implementation, the SWT main() has to be run on Thread 0. As I understand the architecture, they don't actually create a permanent runloop, but rather pump events themselves. Since Thread 0 is the only place these events get delivered, their main() has a hard requirement to be run on Thread 0, at least on the Mac.
When we know the AWT is running the show, we do send a shutdown message to the Cocoa runloop when JVM has detected it is exiting naturally. Since SWT controls their own lifecycle we know not to shutdown the runloop from under them (which is just like the embedded case, like plugins inside say, Safari).
Cheers,
Mike Swingler
Java Runtime Engineer
Apple Inc.