I hereby propose that: 1) Callbacks will be executed synchronously. No other events will be handled until a callback returns. Rationale: *) This maps directly to the execution model of all backend toolkits that I know *) You can easily get concurrency by calling forkIO, but going the other way is difficult. 2) Calls to the CGA can be made at any time, from any thread. The implementation is responsible for assuring that the serialization requirements of the backend toolkit are met. Number 1) is easy. Number 2) is more work for implementations, but it is necessary so that concurrent GUIs can easily be built on top of the CGA. Point 2) probably requires wrapping each and every foreign call in a CGA backend with some synchronization code. And I have one question: How many of the toolkits we are targeting support posting a user-defined event from a different OS thread than the event loop? AFAIK, Win32 and Mac OS Cocoa/Carbon do. We will have to choose between 2a) and 2b): 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... :-) Cheers, Wolfgang