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.