Re: OS/X Java native bug
Re: OS/X Java native bug
- Subject: Re: OS/X Java native bug
- From: Michael Hall via Cocoa-dev <email@hidden>
- Date: Sun, 19 Mar 2023 14:38:58 -0500
> On Mar 19, 2023, at 1:02 PM, Alan Snyder <email@hidden> wrote:
>
> Your comments don’t make sense to me.
>
> You either post an event to run the code on the main thread or, if you are on
> the main thread, you run the code directly.
>
> Running the code directly is what invoking a block does.
>
> How is that unnecessary?
>
> Would it make more sense if the parameter were named “c” and the code said
> “c()”?
>
Alan,
The code here does seem pretty straight forward. Never the less this is where
it hangs. If you run the example in the bug report with -XstartOnFirstThread
and then do a shift+ctrl+\ you should see this on the stack trace.
It doesn’t run the block with the hang. NSLog traces show that.
So I assume something is wrong prior to here that is causing the problems.
So I started trying to back trace how you get here. That led me to the code
that indicates with the switch you don’t get the same setup Swing app’s
normally do but are supposed to manage things yourself - like run loops.
My best guess now is that the hang is because some necessary setup to run Swing
is not being done with the -XrunOnFirstThread switch.
If you look at the earlier sort of full trace I provided I point out one case
where you end up in ThreadUtilities doing a block copy that happens without the
switch but doesn’t happen with the switch.
Things are somehow different and without possibly some fairly complicated
native you aren’t going to be able to get this to work.
I just don’t think this was ever intended to be used by normal Swing
applications.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden