Darwin OpenJDK 7 Binaries - Not Working With SWT

[Mike Swingler]

On Oct 12, 2008, at 2:25 PM, Michael Franz wrote:

> On Sun, Oct 12, 2008 at 3:38 PM, Mike Swingler <swingler at apple.com>  
> wrote:
>
> On Oct 12, 2008, at 12:26 PM, Michael Franz wrote:
>
>> On Sun, Oct 12, 2008 at 11:21 AM, Mike Swingler  
>> <swingler at 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 at 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.
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081012/1521f529/attachment.html