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

[Wolfgang Thaller]

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