On Oct 12, 2008, at 12:26 PM, Michael Franz wrote:

On Sun, Oct 12, 2008 at 11:21 AM, Mike Swingler <swingler@apple.com> 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.

There are two small patches from SoyLatte that need to be re-implemented for OpenJDK, both of which you have run into:

-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.

Mike Swingler
Java Runtime Engineer
Apple Inc.