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