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

[Daan Leijen]

Hi Wolfgang,

Thanks for your concrete proposal!

> 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.

Good plan. Just to make things more clear, this means that all callbacks are executed sequentially.

> 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.

Unfortunately, you are not clear about what kind of thread you mean: OS thread or Haskell thread?

I therefore propose another rule:

2d) All haskell code is run in a single OS thread  (the "GUI thread"). Calls to the CGA
    can be made at any time from any Haskell thread (within the GUI thread).

Note that:
- We can run many haskell threads within one OS thread. Furthermore, the interaction
  between Haskell threads is well understood and light weight.
- The serialization requirements of the backend toolkit are automatically met since
  all these haskell threads run in the same OS thread.
- All current Haskell systems can easily support this model -- in contrast, no haskell
  system (except the LVM in Helium :-) supports multiple OS threads to my knowledge.
- We can implement all advanced event models on top of this model using concurrency.
- We most surely do *not* want foreign C calls to be run in a different OS thread
  and don't want the "threadsafe" keyword here. (I am opposed to such extension --
  complexity without reason - run your OS threads from C yourself!)

About implementing concurrency:

As you explained, a callback can use forkIO to achieve concurrent callbacks
for example. However a more "real world" reason for having concurrency would
be that a callback needs to do a lot of processing. As callbacks are run
sequentially, the entire application will not react to events while the
callback does its work. Therefore, a callback that needs to do a lot of processing
should spawn a Haskell thread to do the processing (a worker thread) and
return as soon as possible in order to stay reactive.

Now, the big issue here is how to keep those Haskell threads running! At the primitive level, there is an eventloop that waits for events to happen,
pops them of the queue, calls a Haskell callback, waits for its result, and
loops again. When a callback returns that has just forked another Haskell thread,
the eventloop will make an OS call to wait for the next event. Since we are running
in a single OS thread, this will "disable" the Haskell scheduler and the worker thread
will not run at all until another event happens!

The question is how to solve this. Alastair Reid used the "yield" primitive to wait until
all Haskell threads were done (or called yield themselves), but that wouldn't solve our particular problem as we want to stay reactive *and* have a lot of processing to do.

Now, I think that we should use "idle time" events to solve this. It would stay nicely in
our simple concurrency model and also keep the whole GUI desktop reactive (do we remember
the old Winhugs bug :-).  Basically, when an "idle" time event happens we call a callback
that just sleeps for, say, 0.1 seconds, giving the Haskell scheduler time to run other
haskell threads. It would be good of course when we have some hooks to determine whether
there are any haskell threads waiting to be scheduled so we can avoid calling that handler
when not necessary. We don't necessarily have to use real "idle" events: if there are Haskell
treads waiting to be scheduled, we can also peek at the event queue, and when no new events
have arrived, call the idle callback. When all haskell threads are done, we wait again.
Note that this schedule also give more priority to new events, keeping the whole application
highly reactive.

Cheers,
-- Daan.