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

Wolfgang Thaller wolfgang.thaller@gmx.net
Wed, 12 Mar 2003 00:14:54 +0100


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