A few weeks back Esteban Lorenzano of Mars fame http://news.squeak.org/2009/01/08/squeak-goes-to-mars/ asked about the SqueakProxy and Objective C Bridge I've been working on, could he use it to get a callback for oh say windowShouldClose: from an NSWindow instance then have some smalltalk code run, and determine YES or NO? Well that sounds simple, should only take a bit of time,... time passes (lots) and lots of iChat and email pass by too. Now it seems the issue is that on OSX and the iPhone UI related things can only run on the main thread, so let's talk a bit about that history. When the Carbon Squeak VM was ported from OS-9 we actually started the interpreter on a background thread. This worked fine until Apple started enforcing the rule about UI related things can only be run on the main thread as they quickly revised the operating system. The VM was patched to ensure any UI related things were performed on the main thread via a cross thread callback. This worked fine until the Sophie team started to exploit Quicktime for audio/video and graphics. It turned out QuickTime calls *really* needed to be on the UI thread. We could funnel *ALL* the FFI calls to the main thread, but that is expensive. So the carbon VM was changed to co-execute interpreter() on the UI thread via polling logic, where the interpreter runs and polls for UI events to service. This solved the problem of deciding should this FFI call be on the UI thread or the background squeak thread, plus then ensured any plugins etc would always have logic that ran on the main UI thread without having the developers worry their brains over it. The curious might note this explains the odd behaviour of the carbon VM when you toast the morphic event polling process, then it fails to service macintosh menus because it's really waiting for some squeak process to invoke get next event so it can service the pending menu interaction. Now the Unix os-x vm using cocoa is less affected by this, but it will NOT run FFI based quicktime calls, also the iPhone VM is *extremely* broken if you do any UIKit stuff (even allocating UIKit objects) from a background thread. For the iPhone VM you *must* remember to execute objective C calls either on the main UI thread, or the background thread. We have to run the iPhone VM on a background thread because the trick we use for the carbon VM to make it run on the foreground thread is broken on the iPhone. Plus if you don't service UI events fast enough on the foreground thread, then the iPhone watchdog will kill you with exception code 0x0badf00d (yes really). Ok, but given the Squeak VM is running on the UI thread then why can we just deal with the windowShouldClose: Well good question, and days of work. Now it seems when get next event is called, we ask the operating system if there are any pending UI events, if so we ask the operating system to service them. Fine, now the SqueakProxy object enters the mix. On the windowShouldClose: the SqueakProxy instance at some point into this operating system call stack gets the windowShouldClose: message. So what does it want to do, well it wants to let the Squeak interpreter *run* so it can convert the NSInvocation instance into a squeak message send, send a windowShouldClose: to the Smalltalk SqueakProxy instance and set the return value, then of course return back to the caller which is 238 levels (well maybe 10) down from the Interpreter's call to the operating system request to service the UI event. Well see the problem I'm already buried in the Interpreter, but need to go back. Now fortunately others have had this *same* issue. http://bugs.squeak.org/view.php?id=6669 I note the Smalltalk code has been integrated into VMMaker many months/ years ago, but the virtualMachine.c/h has not been updated. I further note it works just like advertised. So now when the UI thread enters the SqueakProxy objective-c instance I just do if (isCarbonVM) interpreterProxy->callbackEnter(&callbackid); The simplistic viewpoint is that this call lurches the interpeter() awake (well and lots of other stuff). The smalltalk code runs, and then invokes a primitive to do the interpreterProxy->callbackLeave(callbackid) which longjmps me back to the original point of the callbackEnter() so I continue the flow of finishing up servicing the windowShouldClose: And everyone is happy. Well assuming this stuff actually works, and there isn't some pending callbackEnter/callbackLeave VM changes that have never flowed into the mix, and where how does the Alien support collide, or not collide with all this trickery. Anyway it seems Esteban might get his windowShouldClose: tomorrow. Certainly he can be the first beta tester. -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================