[Haskell-cafe] Re: Bound threads

[Duncan Coutts]

On Thu, 2005-03-03 at 12:12 +0100, Marcin 'Qrczak' Kowalczyk wrote:

> I was thinking about integration with gtk/glib event loop.

Yes please!

Currently GUI libs (gtk2hs, wxHaskell, fltk, etc) cannot use threads in
any sensible manner.

I think think there are two problems with this. One is that all GUI
Haskell threads must be bound to a single OS thread as GUI libs (apart
from opengl) are not thread safe. (This is not the same as the current
bound thread mechanism which allows to bind a fresh OS thread to new
Haskell threads.)

The other problem is then once all GUI Haskell threads are running in
the same OS thread as the GUI main loop they have to somehow cooperate
to share cpu time. This is where the GUI event loop integration comes
in.

>  There are
> two ways: either we ask glib to poll using a function supplied by us,
> or we perform polling using glib functions instead of raw epoll / poll
> / select. The first choice seems better because otherwise callbacks
> registered at glib were started from the scheduler and this will not
> work, it's even not clear on behalf of which thread they should run.
> In this case we must provide a function with an interface of poll().

I tried a hack once where we install ghc rts as an event source in the
glib main loop. The idea is that we ask the ghc rts if it has any
runnable threads and if so we give it a timeslice. The glib event source
API can also use information about file descriptors and timers.

This sort of worked. To do it properly would require the rts to have an
interface to do this. I was doing it just by importing lots of rts
private header files.

A crucial point is that all callbacks must happen in the same OS thread
that originally started the GUI main loop.

Duncan