Re: Re: events & callbacks

Daan Leijen <[email protected]> writes:
> One can implement all other models on top of this: - you just keep
> this model and use callbacks. This is what GIO, HsGTK and TkGofer
> do.  - you make the callbacks behave concurrently (this would lead
> to the bug in the example though). How could you do that? 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.

Note that HGL (which works on both Hugs and GHC) does something a lot
like what you describe.  The reason it works on HGL is that the event
loop thread calls 'yield' before executing the blocking call to get
the next event (on X11) or returning from the event callback (on
Win32).  Yield pushes the current thread down to the lowest priority
so all the other threads get to run until they terminate, block or
yield before the event loop thread gets to continue.

[Caveat: The semantics of yield is the Hugs semantics, the GHC
semantics are a little different and should, perhaps be strengthened.]

In short, it's perfectly possible to have the callbacks run
concurrently.  Whether it's a good way to structure systems I leave to
the usual contributors to this list.

--
Alastair Reid                 [email protected]  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/