Q regarding threading issues for SWT mode

[Scott Kovatch]

On Dec 14, 2011, at 5:10 AM, Anthony Petrov wrote:

> The only issue that is still unclear to me is when an app is started on main thread (to use SWT later), but accesses AWT first (like the one mentioned in MACOSX_PORT-720 - it creates an instance of the Font class before doing anything else).
> 
> In this case we'll create a simple NSApplication instance by means of calling the NSApplicationLoad(), however, since Cocoa SWT hasn't started its event loop (and hasn't even been initialized yet), [NSApp isRunning] will return NO, and hence we'll start an AWT event loop at line 354.

Hmm… This should be okay. Have you tried it yet? I believe when you use NSApplicationLoad() it treats the NSApplication as being in the running state.  At least, I hope that's still the case. Otherwise this design falls apart. :-\

> Will SWT be able to take control of the event loop later? Or will it be able to put up with AWT spinning its own event loop? Or will it simply fail to start up?

No, this is a bad thing. SWT needs to have full control over creating its own NSApplication and running the event loop. SWT then becomes the event pump that also dispatches AWT events to AWT windows. That's because it ignores events not targeted to its windows and lets the base NSApplication event dispatcher handle it. If the AWT is allowed to create and run an NSApplicationAWT, it will sit in [NSApplication run] and never get back out. We'll never get back to the main thread so the SWT can create a Display.

> Or do we simply not support such use case? I.e., should we just require apps to initialize SWT first prior to using any of the AWT APIs?

This did work with Apple's JDK 6, so I would expect it to continue to work with 7.

- Scott