> I posted the Java and OS info below.
>
>> So you found a regression due to our huge change of locking.
>
> In fact, I'm also experiencing another deadlock issue in Processing, but I
> didn't bring up at first since it involves native libraries and video, so I
> don't know how to report it through a small test case. But since you mention
> that you have done major changes in the locking mechanism in JOGL, I just want
> to point out to it because it might indicate other potential issues/regressions.
>
> Very briefly, I'm pre-rolling capture devices (webcams, etc) to get the the
> device's supported resolutions and framerates. I do this through some native
> code written in Objective-C, which gets called via JNA in the first frame of
> my app in Processing/Java. This pre-rolling involves waiting a bit for the
> camera to start capture, getting a few frames, and then shutting down the
> camera. So I have something along these lines:
>
> // Initial delay
> NSRunLoop *mainRunLoop = [NSRunLoop mainRunLoop];
> if ([mainRunLoop currentMode] == nil) {  
>   [[NSRunLoop mainRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
> }
>
> // Wait until the delegate method gets a bunch of frames....
> while (!gotFrame) {
>     [[NSRunLoop mainRunLoop] runUntilDate:[NSDate
> dateWithTimeIntervalSinceNow:0.1]];
> }  
>
> In any case, this used to work w/out any problem until I updated to the
> autobuild jars from Oct 29th. After that, the Java program would hang when
> doing this pre-rolling in native code. Again, if I encapsulate the Java call
> that triggers the pre-rolling inside a EventQueue.invokeLater(), then the app
> doesn't hang. So I feel this is related to the same regression that causes the
> deadlock when trying to set the title of the frame. Same as before, everything
> gets called from the EDT, although the native calls might be happening in a
> separate thread, this I'm not sure about.