[wxhaskell-users] Dealing with threads

[Duncan C. <dun...@wo...>]

All,

I gather that wxHaskell does not yet work nicely with multiple Haskell
threads (eg the long computation in a separate thread in order to show a
progress bar).

I'm working on the same issue with gtk2hs and was hoping we could
coordinate in designing a solution and in talking to the ghc developers
if necessary.

Current solutions are not very satisfactory, one can either add an idle
handler that periodically yields to the ghc rts, or sprinkle your long
running action with calls to yield to the gui main loop.

The former is not good because it is basically polling which costs cpu
time, even when your app should be idle. The latter is either difficult
and annoying or impossible; the long running process may involve code
from a different library that knows nothing of GUIs (which you would
have to modify) or may even be pure code in which case you can't yield
to the gui main loop at all.

While using multiple threads may well not be a good technique for GUIs
written in traditional languages (since the locking issues with OS
threads are considerable), using lightweight Haskell threads should be a
nice way of structuring GUI programs in Haskell. There are a couple
research papers on this theme. Also, if we can make sure that all the
Haskell threads accessing the GUI are running in the context of the same
OS thread then there are no locking issues.

So here's some of my ideas for what we would want:

I would see as the goal, a solution that allows multiple Haskell threads
to be bound to the single OS thread (the GUI thread), so that all calls
that query or modify the GUI occur in the same single OS thread.

If we had such a mechanism, then we still have to solve the problem that
the GUI event loop blocks until it gets an event; while we would like to
get control to return to the ghc rts occasionally so that it can service
any active Haskell threads that want to make gui calls. We also want to
be able to do this without polling.

This may require some mechanism to get the appropriate information from
the ghc rts so that the gui event loop can block, and return control to
the ghc rts for one timeslice whenever there are events that ghc's rts
is interested in (timers, io activity etc)

I'm interested in your thoughts on this issue, (especially alternative 
proposals) and what priority you feel it deserves.

Duncan Coutts