[Haskell-cafe] FFI and callbacks

[Simon Marlow]

On 23 July 2005 03:38, Duncan Coutts wrote:

> The problem then as John noted is that the main loop of these toolkits
> block and so the other Haskell threads would not get a chance to
> schedule. So the challenge is to give the Haskell threads a chance to
> schedule.

[ good description of the multi-threaded GUI problem deleted ]

Thanks for describing the problem in detail, I understand it better now.
I think it comes down to this conflict:

 - you want to take advantage of the fact that GHC has lightweight
   "green" threads in order to do multithreading within a single OS
   thread, but

 - our "bound threads" design does not require the implementation
   to support lightweight threads, and hence doesn't let the
   programmer take advantage of them.

When we were thinking about bound threads, the idea was to accommodate
multiple implementations including the one-to-one and giant lock
approaches.  We consider(ed) GHC's mixture of lightweight and
heavyweight threads to be an optimisation.

However, the GUI library example is interesting, because if we could
take advantage of lightweight threads it seems we could have
multithreaded access to the GUI with better performance and no
requirement to make all GUI calls from a single thread.

But I'm not convinced.  There are advantages to using the single GUI
thread approach, and we don't have any measurements for whether the
overhead is too much.  Suppose you set up a channel containing requests
of type (IO a, MVar a), where the MVar takes the result.  You can build
a combinator

  withGUI :: IO a -> IO a

to perform a GUI operation (and this allows you to try multiple
approaches without changing the code).  Using withGUI you can send a
whole batch of GUI operations in one go, it doesn't have to be one
request per GUI call.  You could also build

  asyncGUI :: IO a -> IO ()

which fires off a GUI request that doesn't require a result, and
combines it with existing requests in a single batch if possible.
Ordering would be retained, of course.

The GUI thread will run multiple requests sequentially, it doesn't have
to context switch between each request.  And you get more parallelism,
because the other threads continue to run while the GUI thread is in the
main loop.

Cheers,
	Simon