lablgtk bugs

Jacques Garrigue garrigue at
Fri May 4 01:29:17 CEST 2001

From: Nicolas GEORGE < at>

> Le quartidi 14 floréal, an CCIX, Jeff Henrikson a écrit :
> > 2) Is there a way to repaint a window in a multithreaded app from a
> > non-drawing thread?  It seems that most of the examples just call their
> > own paint handlers directly.
> Yes, it is quite common.
> >				This is bad when you have multiple theads
> > because to get your drawing right it's best to have only one thread
> > drawing.
> Right. More : Gdk doesn't allow to use graphics primitives in more than
> one thread. Note that if you are using bytecode version without system
> threads, this is not a problem ; but you can not rely on that.

Well, I studied the threading code in ocaml a while before reaching
the conclusion that this is OK, even with native code using system

That is, the system makes sure that all calls to gdk are
single-threaded. You don't have to bother at all about threading
issues ---as long as you don't have independent C threads using GTK in
your application, a problem I had when linking a lablgtk program with

Why is it so? Basically, the caml runtime uses a big lock, to make
sure that only one thread is running caml code at any time (mainly for
GC reasons I believe). This lock is only released when calling some
specific C functions, to allow them to block. But calls to the GDK do
not release the lock, so you can only have one single call to the GDK
occuring at a time. You may switch to another concurrent C thread at
that time, but you will not be able to go back into caml code to
initiate another GDK call.

Also, I took some care of making lablgtk itself re-entrant.

I hope this is correct. Actually we had some multi-thread GDK
application running, and didn't bother about from where to call
functions at all.

Best regards,

Jacques Garrigue      Kyoto University     garrigue at
		<A HREF=>JG</A>

More information about the Lablgtk-list mailing list