Darwin OpenJDK 7 Binaries - Not Working With SWT
Hi, I downloaded and tried to use the Darwin OpenJDK 7 binaries with the Eclipse 3.4 Samples. This uses all of the SWT components. The application will not start as the JVM does not understand the -XstartOnFirstThread flag. There error message is: Unrecognized option: -XstartOnFirstThread Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. I have not been able to figure out what this option does, I think it has something to do with the integration between AWT and SWT and the EDT. Michael
On Sep 7, 2008, at 9:09 AM, Michael Franz wrote:
Hi,
I downloaded and tried to use the Darwin OpenJDK 7 binaries with the Eclipse 3.4 Samples. This uses all of the SWT components. The application will not start as the JVM does not understand the - XstartOnFirstThread flag.
There error message is: Unrecognized option: -XstartOnFirstThread Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
I have not been able to figure out what this option does, I think it has something to do with the integration between AWT and SWT and the EDT.
This is because OpenJDK7 does not have a Cocoa-based AWT that must start on thread 0 to receive events from the OS. If you simply remove the -XstartOnFirstThread argument, or apply a patch to OpenJDK (which I believe SoyLatte did) to ignore this "VM flag", everything should start fine. Mike Swingler Java Runtime Engineer Apple Inc.
This is because OpenJDK7 does not have a Cocoa-based AWT that must start on thread 0 to receive events from the OS. If you simply remove the -XstartOnFirstThread argument, or apply a patch to OpenJDK (which I believe SoyLatte did) to ignore this "VM flag", everything should start fine.
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. I am now getting an unsatisfiedlinkerror. When I run from the command line using the Apple 1.5 JVM and then using the OpenJDK. The Apple version works. The OpenJDK produces: Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-cocoa-3448 or swt-cocoa in swt.library.path, java.library.path or the jar file at org.eclipse.swt.internal.Library.loadLibrary(Library.java:233) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151) at org.eclipse.swt.internal.C.<clinit>(C.java:21) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:620) at org.eclipse.swt.widgets.Display.create(Display.java:613) at org.eclipse.swt.graphics.Device.<init>(Device.java:113) at org.eclipse.swt.widgets.Display.<init>(Display.java:536) at org.eclipse.swt.widgets.Display.<init>(Display.java:527) at org.eclipse.swt.examples.controlexample.ControlExample.main(ControlExample.java:202) The command I execute /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/java -Djava.library.path=/Users/mfranz/Documents/eclipse-3.4/workspace/org.eclipse.swt.cocoa.macosx -Dfile.encoding=MacRoman -classpath /Users/mfranz/Documents/eclipse-3.4/workspace/org.eclipse.swt.examples/bin:/Users/mfranz/Documents/eclipse-3.4/workspace/org.eclipse.swt/bin:/Users/mfranz/Documents/eclipse-3.4/workspace/org.eclipse.swt/extra_jars/exceptions.jar:/Applications/eclipse-3.4/plugins/org.eclipse.swt.carbon.macosx_3.4.0.v3448f.jar org.eclipse.swt.examples.controlexample.ControlExample /Users/mfranz/developer/openjdk-bsd/openjdk7-darwin-i386-20080820/bin/java -Djava.library.path=/Users/mfranz/Documents/eclipse-3.4/workspace/org.eclipse.swt.cocoa.macosx -Dfile.encoding=MacRoman -classpath /Users/mfranz/Documents/eclipse-3.4/workspace/org.eclipse.swt.examples/bin:/Users/mfranz/Documents/eclipse-3.4/workspace/org.eclipse.swt/bin:/Users/mfranz/Documents/eclipse-3.4/workspace/org.eclipse.swt/extra_jars/exceptions.jar:/Applications/eclipse-3.4/plugins/org.eclipse.swt.carbon.macosx_3.4.0.v3448f.jar org.eclipse.swt.examples.controlexample.ControlExample Michael
On Sep 7, 2008, at 1:08 PM, Michael Franz wrote:
This is because OpenJDK7 does not have a Cocoa-based AWT that must start on thread 0 to receive events from the OS. If you simply remove the -XstartOnFirstThread argument, or apply a patch to OpenJDK (which I believe SoyLatte did) to ignore this "VM flag", everything should start fine.
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.
I am now getting an unsatisfiedlinkerror.
When I run from the command line using the Apple 1.5 JVM and then using the OpenJDK. The Apple version works. The OpenJDK produces: Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt- cocoa-3448 or swt-cocoa in swt.library.path, java.library.path or the jar file at org.eclipse.swt.internal.Library.loadLibrary(Library.java:233) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151) at org.eclipse.swt.internal.C.<clinit>(C.java:21) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:620) at org.eclipse.swt.widgets.Display.create(Display.java:613) at org.eclipse.swt.graphics.Device.<init>(Device.java:113) at org.eclipse.swt.widgets.Display.<init>(Display.java:536) at org.eclipse.swt.widgets.Display.<init>(Display.java:527) at org .eclipse .swt.examples.controlexample.ControlExample.main(ControlExample.java: 202)
The command I execute
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/ java -Djava.library.path=/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt.cocoa.macosx -Dfile.encoding=MacRoman - classpath /Users/mfranz/Documents/eclipse-3.4/workspace/ org.eclipse.swt.examples/bin:/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt/bin:/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt/extra_jars/exceptions.jar:/Applications/ eclipse-3.4/plugins/org.eclipse.swt.carbon.macosx_3.4.0.v3448f.jar org.eclipse.swt.examples.controlexample.ControlExample
/Users/mfranz/developer/openjdk-bsd/openjdk7-darwin-i386-20080820/ bin/java -Djava.library.path=/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt.cocoa.macosx -Dfile.encoding=MacRoman - classpath /Users/mfranz/Documents/eclipse-3.4/workspace/ org.eclipse.swt.examples/bin:/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt/bin:/Users/mfranz/Documents/eclipse-3.4/ workspace/org.eclipse.swt/extra_jars/exceptions.jar:/Applications/ eclipse-3.4/plugins/org.eclipse.swt.carbon.macosx_3.4.0.v3448f.jar org.eclipse.swt.examples.controlexample.ControlExample
Sounds like OpenJDK is not recognizing .jnilib files as valid native libraries. Another patch to SoyLatte also allowed it to recognize both .dylib and .jnilib. We also made changes to Java in Mac OS X 10.5 Leopard to recognize .dylib as well as .jnilib. I know it's sounds super-hacky, but I bet if you renamed all your .jnilib's to .dylib's, it will probably work. Best of luck, Mike Swingler Java Runtime Engineer Apple Inc.
I created links that use the dylib extension. The demo fires up, however, it does not work. It draws a big blank square. :( Thanks for all the help. On Sun, Sep 7, 2008 at 5:44 PM, Mike Swingler <swingler@apple.com> wrote:
Sounds like OpenJDK is not recognizing .jnilib files as valid native libraries. Another patch to SoyLatte also allowed it to recognize both .dylib and .jnilib. We also made changes to Java in Mac OS X 10.5 Leopard to recognize .dylib as well as .jnilib.
I know it's sounds super-hacky, but I bet if you renamed all your .jnilib's to .dylib's, it will probably work.
Best of luck, Mike Swingler Java Runtime Engineer Apple Inc.
Hi, Do any other platforms support multiple dynamically load library extensions? I was thinking that the JNI_LIB_SUFFIX could be defined as a space (or comma) delimited list of extensions and then change Java_java_lang_System_mapLibraryName in jdk/src/share/native/java/lang/System.c to be able to handle the parsing of the JNI_LIB_SUFFIX string. The order in the list would specify the search order. Thoughts? Michael
Sounds like OpenJDK is not recognizing .jnilib files as valid native libraries. Another patch to SoyLatte also allowed it to recognize both .dylib and .jnilib. We also made changes to Java in Mac OS X 10.5 Leopard to recognize .dylib as well as .jnilib.
I know it's sounds super-hacky, but I bet if you renamed all your .jnilib's to .dylib's, it will probably work.
Best of luck, Mike Swingler Java Runtime Engineer Apple Inc.
Michael Franz wrote:
Hi,
Do any other platforms support multiple dynamically load library extensions? I don't think there is another one, but on Windows you can have multiple prefixes, depending on the environment: nothing for MSVC++, cyg* for Cygwin, lib* for mingw32 & cegcc, and pw* for pw32. There are no specific ports to either of them, though, so it hasn't been an issue.
Why Darwin has both jnilib and dylib is explained at http://markmail.org/message/nvmhqaimybukzg4l . cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic@sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring
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. dylib vs. jnilib (your current issue): Soylatte first searched for dylib, then fell back to jnilib. OpenJDK only searches for .dylib, with no fallback. Apologies for radio silence on my part, I've been nose down on an iPhone development contract these past two weeks. -landonf
and the -Xdock one, at least NetBeans uses it. Thanks Max On Sep 8, 2008, at 9:22 AM, Landon Fuller 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.
dylib vs. jnilib (your current issue):
Soylatte first searched for dylib, then fell back to jnilib. OpenJDK only searches for .dylib, with no fallback.
Apologies for radio silence on my part, I've been nose down on an iPhone development contract these past two weeks.
-landonf
For the -XstartOnFirstThread patch, was files are relevant for the change? I started to look at src/os/bsd/launcher/java_md.c but not sure that is the correct place Michael 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.
dylib vs. jnilib (your current issue):
Soylatte first searched for dylib, then fell back to jnilib. OpenJDK only searches for .dylib, with no fallback.
Apologies for radio silence on my part, I've been nose down on an iPhone development contract these past two weeks.
-landonf
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. Michael [1] http://blogs.sun.com/ksrini/entry/hotspot_primordial_thread_jni_stack
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. Cheers, Mike Swingler Java Runtime Engineer Apple Inc.
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.
Cheers, Mike Swingler Java Runtime Engineer Apple Inc.
Is it possible to find Thread 0 from other threads? Michael
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.
On Sun, Oct 12, 2008 at 3:38 PM, Mike Swingler <swingler@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@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.
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. Michael
On Oct 12, 2008, at 2:25 PM, Michael Franz wrote:
On Sun, Oct 12, 2008 at 3:38 PM, Mike Swingler <swingler@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@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.
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.
Mike, If the runloop is running on Thread 0, can a thread that is not thread 0 pull events off the runloop by using NSApplication.sharedApplication(). nextEventMatchingMask() ? Where events are the keyboard and mouse events. How does one 'park' thread 0? Michael On Sun, Oct 12, 2008 at 11:21 AM, Mike Swingler <swingler@apple.com> wrote:
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.
Cheers, Mike Swingler Java Runtime Engineer Apple Inc.
On Oct 27, 2008, at 6:43 PM, Michael Franz wrote:
Mike,
If the runloop is running on Thread 0, can a thread that is not thread 0 pull events off the runloop by using NSApplication.sharedApplication(). nextEventMatchingMask() ? Where events are the keyboard and mouse events.
Sorry, nope. I'm pretty sure this method has been tried by the SWT folks.
How does one 'park' thread 0?
pthread_mutex_lock()/pthread_cond_wait()/pthread_cond_signal(). When we load the AWT, we simply signal Thread 0, to continue and start pumping the event loop. If the AWT never comes up, the thread stays parked indefinitely. This is actually just a modification to how the JVM starts when you request a custom thread stack size for the main thread.
Michael
On Sun, Oct 12, 2008 at 11:21 AM, Mike Swingler <swingler@apple.com> wrote:
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.
Cheers, Mike Swingler Java Runtime Engineer Apple Inc.
On Tue, Oct 28, 2008 at 12:34 PM, Mike Swingler <swingler@apple.com> wrote:
On Oct 27, 2008, at 6:43 PM, Michael Franz wrote:
Mike,
If the runloop is running on Thread 0, can a thread that is not thread 0 pull events off the runloop by using NSApplication.sharedApplication(). nextEventMatchingMask() ? Where events are the keyboard and mouse events.
Sorry, nope. I'm pretty sure this method has been tried by the SWT folks.
Just so I am clear, there is no easy way for a thread to get the mouse and keyboard events from Thread 0? A non-easy way might be to implement a producer/consumer pattern. Where thread 0 is the producer and some other thread is the consumer.
How does one 'park' thread 0?
pthread_mutex_lock()/pthread_cond_wait()/pthread_cond_signal(). When we load the AWT, we simply signal Thread 0, to continue and start pumping the event loop. If the AWT never comes up, the thread stays parked indefinitely. This is actually just a modification to how the JVM starts when you request a custom thread stack size for the main thread.
OK, my PThreads book helped clarify this. Thanks for all your input. Michael
participants (5)
-
Dalibor Topic
-
Landon Fuller
-
Max (Weijun) Wang
-
Michael Franz
-
Mike Swingler