Gtk2Hs - A GUI Library for Haskell

On 11.05.2004, at 02:51, Duncan Coutts wrote:

> 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.

I would recommend not to go down that route...

*) It places a high burden on the Haskell implementation - GHC's is the 
only RTS where this is even remotely implementable, whereas the current 
"bound threads" scheme can be implemented in a variety of different 
ways. I like to consider lightweight threads as an implementation 
detail (used to achieve top performance in GHC) and not as a language 
feature that has to be duplicated by all future implementations.

*) Having multiple threads trigger actions in the GUI thread can be 
done without any special support by the RTS (see below).

*) Executing two Haskell threads in one OS thread leads to a lot of 
problems when interacting
with foreign code. Nobody seems to have succeeded in even specifying 
exactly what should happen in all the strange situations that arise 
here. For example, let's assume we have two Haskell threads, A and B, 
running in one OS thread.
Now A calls a foreign function "foo" that takes a long time to execute. 
During this time, B doesn't execute at all, right?
OK, so now after "foo" is finished, A calls another foreign function, 
"bar", which immediately calls back into Haskell. So as soon as the RTS 
is re-entered, B should continue to run?
But what if B calls another foreign function, which in turn calls back 
to Haskell? Now if the A-callback wants to return to bar, will that be 
possible? No, it'll have to wait for that other foreign call in another 
thread.
It's a can of worms, we _don't_ want to go there.

*) Executing two Haskell threads in one OS thread does not solve the 
problem.
Sometimes we want to make library calls A, B and C in order, and not 
have another thread call D in-between; for example because the library 
has some global or thread-local state which we don't want to be messed 
up, or perhaps because we want A, B and C to be done right after each 
other (e.g. updating different parts of one window), and D might take a 
long time (show a dialog box).

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

Well...
let's assume we've imported a few things from some "foreign" GUI 
library (sorry, I don't know much about either gtk or wx, so I'll try 
to stay general):

> runMainLoop :: IO ()	 -- returns only when the program is over, calls 
> lots of callbacks.
> 	-- send a user event to the main loop (wrap the IO action in a stable 
> pointer)
> postUserEvent :: IO () -> IO ()
>
> {-# NOINLINE uiThread #-}
> uiThread = unsafePerformIO $ newIORef (undefined :: ThreadId)
>
> onClick :: ... -> IO () -- just an example
> onClick blah blah blah = do tid <- myThreadId
>                             writeIORef uiThread tid
>                             handleTheEvent
>
> 	-- handle a user event
> onUserEvent :: IO () -> IO ()
> 							
> onUserEvent action = do tid <- myThreadId
>                         writeIORef uiThread tid
>                         action
>
> doInUIThread action = do tid <- myThreadId
>                          uiTid <- readIORef uiThread
>                          if tid == uiTid
>                              then action
>                              else postUserEvent action

And then we can either wrap doInUIThread around every function we 
import from the UI library (slow), or we can use it manually to do 
things in bigger chunks.
I think we do _not_ want the handling of one event to be preempted by 
UI actions from other threads; we might be in the progress of building 
a dialog box in response to a user event, we don't want a background 
thread to display e.g. an error message when we have a half-finished 
dialog box...

Cheers,

Wolfgang

On 11 May 2004, at 02:51, Duncan Coutts wrote:

> 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.

For a nicer solution *now* we could add a function like

doLongComputation :: IO a -> IO a

that installs the callback idle handler before starting the long 
computation and that removes it when the long computation finishes.

> 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.

Using multiple Haskell threads is definitely attractive. If ghc were 
more cooperative and had a hook to install additional file descriptors 
into it's scheduler then - at least in Gtk - you could make GHC do all 
the scheduling by using the Gtk function

void        g_main_context_set_poll_func    (GMainContext *context,
                                              GPollFunc func);

I don't know if wxWindows can do that since it has to be a bit more 
general. But since there are no such hooks, this approach is not very 
attractive.

> 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.
>

Then there is a third option which Wolfgang posted. I'll repeat it here 
in case I got it wrong. Gtk doesn't use thread-local storage and hence 
can be called from several threads as long as the blocking is done 
right. It should work something along these lines:

{-# NOINLINE uiThread #-}
uiThread = unsafePerformIO $ newIORef (undefined :: ThreadId)

gtkMain = forkOS $ do
   g_thread_init
   gtk_threads_init
   gtkInit
   gdk_threads_enter
   gtkMain_
   gdk_threads_leave

foreign import threadsafe "gtk_main" gtkMain_ :: IO ()

All signals are automatically called from gtkMain without releasing the 
Gtk thread (exceptions are mentioned on this website:
http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html
)

Unfortunately, the Gtk functions are not all wrapped in a 
gdk_threads_enter/leave pair. Hence we have to do it ourselves with a 
helper function:

concurrentGuiUpdate :: IO a -> IO a
concurrentGuiUpdate action = do
   myId <- myThreadId
   uiId <- readIORef uiThread
   if myId==uiId then action else
     gdk_threads_enter >> action >> gdk_flush >> gdk_threads_leave

I think this code does more or less the same as Wolfgangs solution but 
uses a Gtk supplied feature: Each time the main loop goes round (or is 
actually idling) the lock is released which gives an opportunity for 
other threads to acquire the lock. Calling an action from within a 
signal handler doesn't have to be wrapped with concurrentGuiUpdate (but 
no harm is done due to the thread id check). Calls from the main thread 
have to be wrapped, though.

We could supply concurrentGuiUpdate and doLongComputation and replace 
either one with a no-op, depending on what is available.

Axel.

> Unfortunately, the Gtk functions are not all wrapped in a 
> gdk_threads_enter/leave pair. Hence we have to do it ourselves with a 
> helper function:
>
> concurrentGuiUpdate :: IO a -> IO a
> concurrentGuiUpdate action = do
>   myId <- myThreadId
>   uiId <- readIORef uiThread
>   if myId==uiId then action else
>     gdk_threads_enter >> action >> gdk_flush >> gdk_threads_leave
>
> I think this code does more or less the same as Wolfgangs solution 
> [...]

Yes, should be the same (minus thread-local state, which you say isn't 
needed for gtk).
One minor point might be that with my code, multiple nested 
doInUIThread are cheap, while here
(concurrentGuiUpdate . concurrentGuiUpdate) does something strange; 
that should be easy to fix, though.

Cheers,

Wolfgang

On Tue, 2004-05-11 at 20:44, Axel Simon wrote:
> For a nicer solution *now* we could add a function like
> 
> doLongComputation :: IO a -> IO a
> 
> that installs the callback idle handler before starting the long 
> computation and that removes it when the long computation finishes.

Just a quick recap/summary,

When using the single-threaded rts this will work fine, we install an
idle handler that yields to the rts occasionally so the long computation
can progress. This also works if the long computation wants to fiddle
with the gui since it is all happening in the single OS thread, no
locking problems.

When linking using the -threaded rts this is unnecessary since the call
to gtk_main will be run in a new OS thread and so other Haskell threads
can make progress anyway, however the long computation cannot make any
gui calls unless it uses one of the other locking mechanisms you've
described, either "post task to main loop" or
gdk_threads_enter/gdk_threads_leave.

> Using multiple Haskell threads is definitely attractive. If ghc were 
> more cooperative and had a hook to install additional file descriptors 
> into it's scheduler then - at least in Gtk - you could make GHC do all 
> the scheduling by using the Gtk function
> 
> void        g_main_context_set_poll_func    (GMainContext *context,
>                                               GPollFunc func);

Yes, that the other way of doing it, instead of installing ghc into
gtk's main loop, install gtk into ghc's rts event loop. 

The primitives that ghc gives for blocking only block on one fd, or a
timer, but you could simulate poll at the moment by spawning a Haskell
thread for each fd that the poll func wants to block on (and one for the
timeout), synchronise them all with an MVar and kill the threads that
didn't unblock. Not terribly efficient of course.

This would allow us to use the single threaded rts and still have
Haskell threads make progress. We still wouldn't be able to use the
threaded rts without the locking stuff.

> I don't know if wxWindows can do that since it has to be a bit more 
> general. But since there are no such hooks, this approach is not very 
> attractive.

It doesn't seem impossible to add a threading primitive:
threadWait :: Int -> [Fd] -> [Fd] -> IO ()
threadWait timeout readFds writeFds = ...
-- Block the current thread until data is available to read on any of
the given read file descriptors, or until data can be written to any of
the given write file descriptor, or until the given number of
microseconds has passed.

Not that I'm suggesting that at the moment of course.

It's probably not that easy either since I think one of the rts's basic
assumptions is that each lightweight thread can be blocked on only one
fd or a timer at once.

> Unfortunately, the Gtk functions are not all wrapped in a 
> gdk_threads_enter/leave pair. Hence we have to do it ourselves with a 
> helper function:
> 
> concurrentGuiUpdate :: IO a -> IO a
> concurrentGuiUpdate action = do
>    myId <- myThreadId
>    uiId <- readIORef uiThread
>    if myId==uiId then action else
>      gdk_threads_enter >> action >> gdk_flush >> gdk_threads_leave
> 
> I think this code does more or less the same as Wolfgangs solution but 
> uses a Gtk supplied feature: Each time the main loop goes round (or is 
> actually idling) the lock is released which gives an opportunity for 
> other threads to acquire the lock. Calling an action from within a 
> signal handler doesn't have to be wrapped with concurrentGuiUpdate (but 
> no harm is done due to the thread id check). Calls from the main thread 
> have to be wrapped, though.

Of course whatever you do inside concurrentGuiUpdate cannot block, so
you can't put your whole long running computation inside that, it'd have
to be just the bits that modify the gui, eg from the Progress demo:

doTask :: ProgressBar -> IO ()
doTask pb = do
  concurrentGuiUpdate (progressBarPulse pb)
  putStrLn "progressBarPulsed"
  threadDelay 100000
  doTask pb

> We could supply concurrentGuiUpdate and doLongComputation and replace 
> either one with a no-op, depending on what is available.

Right, concurrentGuiUpdate is a no-op for the single threaded rts and
doLongComputation is a no-op for the threaded rts.

I still think it would be nicer to be able to heap the responsibility of
thinking about locking/concurrency on the rts by simply declaring that
all these gui threads will be bound to a single OS thread, then there's
no locking and no problem!

It may actually be easier to use Haskell threads for gui stuff if we
stick to the single-threaded rts, then all we have to worry about is
getting called back sufficiently often so that other Haskell threads can
make progress. We can do that with our current yield solution or main
loop integration by replacing gtk's poll or similar.

Duncan

On Tue, 2004-05-11 at 20:44, Axel Simon wrote:
> Then there is a third option which Wolfgang posted. I'll repeat it here 
> in case I got it wrong. Gtk doesn't use thread-local storage and hence 
> can be called from several threads as long as the blocking is done 
> right. It should work something along these lines:
[snip]
> Unfortunately, the Gtk functions are not all wrapped in a 
> gdk_threads_enter/leave pair. Hence we have to do it ourselves with a 
> helper function:
> 
> concurrentGuiUpdate :: IO a -> IO a

> I think this code does more or less the same as Wolfgangs solution but 
> uses a Gtk supplied feature: Each time the main loop goes round (or is 
> actually idling) the lock is released which gives an opportunity for 
> other threads to acquire the lock. Calling an action from within a 
> signal handler doesn't have to be wrapped with concurrentGuiUpdate (but 
> no harm is done due to the thread id check). Calls from the main thread 
> have to be wrapped, though.

This works fine, try the attached patch if you're interested.

I've not done the bit with the IORef that remembers the gui thread
because at the moment, that will identify the Haskell thread, not the OS
thread, I'm not quite sure how we do the latter, so I've left it for the
moment.

So we just modify the Progress.hs demo to add a call to
concurrentGuiUpdate:

doTask pb = do
  concurrentGuiUpdate (progressBarPulse pb)
  threadDelay 100000
  doTask pb

Then when we compile the demo, use the extra ghc command line option
'-threaded' to use the multi-threaded rts (only on ghc-6.2.1)
(on ghc 6.2 built using --enable-threaded-rts no extra option is
necessary)

I'd say this is a reasonable intermediate solution. It's not an ideal
solution of course because the user has to think about where to use
concurrentGuiUpdate (and their program could segfault or cause an X
error if they get it wrong!)

Should we polish this code up and add it as the currently recommended
way of doing threads with gtk2hs or hold out for something better?

Duncan