2008/9/16 John M McIntosh <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
