> On Mar 19, 2023, at 1:02 PM, Alan Snyder <applemail832...@cbfiddle.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
