2008/9/16 John M McIntosh <johnmci@smalltalkconsulting.com>:
On Sep 14, 2008, at 12:39 PM, Igor Stasenko wrote:
My wish behind all of this is to provide clean separation between core VM and UI. Then, in Hydra each image could create and manage own windows.
To complicate things on os-x (macintosh, iPhone) any UI related calls can only be done on the main thread. Thus you cannot open a window, draw, or check the window size, etc on thread 27....
Solving this problem on os-x with the current macintosh VMs requires the VM to be clever.
This clever coding does not work on the iPhone, although this is an open bug with Apple.
For the iPhone we build a "graphic atom" for each display request. On the flush to screen call, we then bundle up the queued atoms and create a "frame update request" which is then executed as a frame region invalidate request on the main thread via a cross thread API call. This triggers (later) an update event on the main thread for the invalidated frame or frames, where we remove the frame update request or requests from the queue, and paint the queued frame updates
Well, i don't see much problem with it. For instance, to get more uniform model, i wanted to rewrite UI events mechanism with events which i use in Hydra for passing any UI related events to interpreter. In this case, you could have an OS-dependent event sink in main thread, and then dispatch events to be handled in another thread(s). I think that event model, which i introduced in Hydra could do this quite efficiently and with no much complexity overhead. Same could be done in reverse order - when you need to invoke some function only from main thread - you could simply enqueue an event into main thread with proper function, and eventually it will be handled, calling your code and using your params..
Another issue which perhaps is not obvious is that FFI calls then might need to run on the main thread, some are not clear, for example executing many QuickTime calls (seemly non UI related) on a secondary thread causes a core dump.
Well, this kind of problem, fairly, is not related to VM - you can't guarantee thread safety from VM side if you allowing foreign calls. Some calls could work, some could crash a system - its completely depends on a functions which you calling.
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.