On Wed, 2006-11-15 at 01:29 +0000, Neil Mitchell wrote:
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.)
Do these work for my particular application? (running a process in the background, and sending its stdout to a Gtk Window). The polling I implemented didn't work very well at all.
Yeah, we did have that weird problem on windows with the single threaded rts that we never tracked down. However I get the feeling that we shouldn't be putting too much effort into fixing the single threaded rts on windows as it will not be around for ever.
Plan 2: Make the threaded rts do what we want.
This is hard and involves begging Simon M to do lots of work.
How many people are required to beg? I volunteer :)
Heh :-) Well it's got to be clear that it's worth the effort. We don't want to steal too much of his paper-writing time.
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.
Can I read a file in a GUI thread? Can I spawn a process and read an external handle? I suspect that more and more things would be added to the GUI monad until GUI == IO.
Aye, there would be methods to get between them. So you could do IO in the GUI monad using liftIO, and perhaps another liftIO variant for IO actions that would block. So we wouldn't need to keep adding things to the GUI monad. The crucial ones would be for liftIO, forkGUI and MVar-style synchronisation. Duncan