Concurrency (was: Re: [GUI] Re: events & callbacks)

[Axel Simon]

On Wed, Mar 12, 2003 at 11:35:58AM +0100, Wolfgang Thaller wrote:
> I hereby propose that:
> 
> 1) Callbacks will be executed synchronously. No other events will be 
> handled until a callback returns.
 Minor detail: There are these Win 3.1 style peekEvent functions in Gtk 
which let the event loop run a little bit to keep the GUI responsive 
(which means that other callbacks can be triggered). If this 
functionality is useful and supported, then your definition needs to be 
refined.


> 2a) If the CGA is currently waiting for an (OS-toolkit-level) event, it 
> is possible that a call to the CGA from another concurrent Haskell 
> thread will be blocked until an event arrives.
> 
> 2b) If the CGA is currently waiting for an (OS-toolkit-level) event and 
> another concurrent Haskell thread calls into the CGA, the CGA backend 
> implementation has to make sure that the call can be handled in a 
> reasonable amount of time (e.g. by posting an application-defined event 
> or by registering a regular timer event).
> 
> Can we have a vote on this, and, if we agree, put this down in the 
> specification? We have to make some progress here sooner or later...
> 
> My vote is for 1), 2) and 2b), unless somebody convinces me of 
> something else... :-)
 Yes, I agree. Actually, when we have OS-threads in ghc, then 2a)  
seems to be more difficult to implement than 2b). Any program which does 
anything else than serving GUIs needs 2b), so it is really the only 
choice.

Axel.