[Haskell-cafe] what GUI library should i select?

[Duncan Coutts]

On Tue, 2006-11-14 at 10:40 +0000, Simon Peyton-Jones wrote:
> I wonder whether it'd be possible to make the gtk2hs stuff emit
> warnings if you make calls from two different threads?  Then an
> application would complain constructively rather than "becoming
> unstable".

I have three plans:

Plan 1: prevent gtk2hs initialising when using the threaded RTS.

This is what the dev version does at the moment to prevent people
shooting themselves in the foot.

Obviously this is not satisfactory as long term the threaded rts is
going to be the only option available.

The funny thing is that we can actually use Haskell threads with Gtk2Hs
perfectly well with the single threaded rts (we currently use a polling
scheme to to cooperative scheduling between gtk+ and ghc rts but there
are some non-polling possibilities that could be implemented.)

Indeed, we used to be able to have GUI stuff work fine in GHCi, but now
that GHCi uses the threaded rts we're in trouble.


Plan 2: Make the threaded rts do what we want.

This is hard and involves begging Simon M to do lots of work. The
constraints we have are that only the OS thread that initialised the GUI
can make calls to the GUI lib. So any Haskell threads doing GUI stuff
have to be running on that OS thread. Note that this really means one OS
thread, not one capability which can run on a pool of threads (with X11,
the pool might be ok as only one would be doing GUI stuff at once but on
Win32 the restrictions are even tighter). I really don't want to make
the Haskell coders have to deal with passing actions between threads to
get it right, because people will get it wrong too easily. So any thread
cunning needs to be hidden in the library so that people cn just use
threads willy nilly without there being dangerous unchecked conditions.

So one idea is to start the UI in a bound OS thread, but then we also
want to make sure that any Haskell thread that makes a GUI call only do
it in that same OS thread. Currently we cannot bind several Haskell
threads to a single OS thread. From discussions with Simon M it is clear
that making this possible is non-trivial. Then even once we have that,
to make it transparent we'd need to be able to migrate a Haskell thread
to the right OS thread if it makes a GUI call. The GUI wrapper lib would
need to arrange this and arrange for cooperative scheduling on the one
OS thread.

Lots of work.

The reason we can't just post actions to the right thread all the time
is that GUI calls are typically very short lived. Many are just reading
fields out of C struts. If every one of those needed an OS thread switch
then it'd be pretty bad. So thats why we'd need to migrate the thread
since that's a one off and after that GUI calls would be quick.


Plan 3: perhaps the IO monad isn't the right monad

It's really quite convenient to have complete access to the IO monad
when doing GUI stuff and that seems to be the design that most recent
libs have chosen.

So suppose we had a GUI monad and the boundaries between the IO and GUI
monad would take care of making sure we were using the right OS thread.

So we would initialise the GUI and then work inside the GUI monad. It'd
fork a bound thread to run the GUI lib's event loop. It'd also have to
arrange for cooperative scheduling in that OS thread. Then the GUI monad
could have a forkGUI that uses Haskell level scheduling to schedule
several GUI 'threads' in the single bound Haskell thread.

Then to do IO, we could provide an escape hatch to do IO, for blocking
stuff we could forkIO and let it run in an unbound thread. Similarly for
long running pure computations we could provide something (or just par?)
to let those run outside the GUI thread so that it doesn't block the UI.

So you'd be able to lift IO stuff into the GUI monad. As for the other
way around, I guess that could arrange for the GUI action to be added to
the GUI scheduler run queue.

Tricky bits: callbacks get run in their own unbound Haskell thread which
would therefore not run in the bound OS GUI thread. That'd be annoying
as it'd involve 2 pointless context switches per callback event. Is
there any way we could be a bit less strict. All we need is that the GUI
Haskell thread runs in the GUI OS thread, we don't mind if other Haskell
threads run in that OS thread too. So a could a callback that comes in
on that OS thread spark a Haskell thread in that same OS thread? Then we
could add the callback action to the Haskell GUI thread's runqueue and
yield to that thread.

So we might still need some RTS changes to make it work nicely. Sigh.

I'd welcome other suggestions.

If we can make it work nicely it should be great. Using light weight
threads is a nice approach to GUIs compared to the contortions that
people have to do in other languages to do everything in an event driven
style to share a single thread while avoiding ever blocking.

Duncan