Daan Leijen wrote:
On the primitive level, nothing runs concurrent. This means that you can register other handlers etc. since no other event will be handled while you are doing haskell work. On the primitive level there is an eventloop that gets an event from the (OS maintained) event queue, calls haskell with the event as argument, and when haskell returns it waits again. [...] well, when in Haskell, you fork a thread to handle an event and return directly. Would it work? No! because the eventloop will immediately wait for the next event. As this is a C call, the haskell runtime system will not run any haskell threads.
That is not guaranteed, it is not part of the FFI specification. Future Haskell implementations will support concurrently executing Haskell and foreign code, and people (for example myself) will want to take advantage of this. The next major version of GHC will probably continue to execute Haskell threads while foreign calls are in progress ("threadsafe" foreign calls). Also, I have to note that some platform-specific (C-language) GUI APIs require that some operations are executed from a certain OS thread (Apple's libraries, but perhaps also some parts of Win32, I haven't investigated exactly). There's a discussion on ffi@haskell.org about how to extend the FFI to handle this. Therefore I think that we should either a) specify that the CGA has to provide all the necessary synchronization to ensure proper operation in the presence of concurrency (this might be done using mvars). b) specify that the CGA may only be used when proper serialization is ensured by the user. I'm strongly in favour of a), as b) will cause a lot of trouble for the library user in the presence of "threadsafe" foreign calls, and even more trouble when the backend library wants to be called only from a certain OS thread (mostly the "main" thread). I do agree that we should not require concurrency for CGA, i.e. that all callbacks should run synchronously and map as directly as possible to the callbacks supplied by the underlying back end libraries. When we have "threadsafe" foreign calls and the CGA is properly protected against concurrent invocation, then concurrent callbacks, events, whatever can easily be implemented on top of that. Cheers, Wolfgang