Delivered-To: lablgtk at yquem.inria.fr
Date: Fri, 04 Apr 2008 09:45:19 +0900 (JST)
Message-Id: <20080404.094519.129733357.garrigue at math.nagoya-u.ac.jp>
To: Luca.Saiu at lipn.univ-paris13.fr
Subject: Re: [Lablgtk] Threads, lablgtk and lablglade
From: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
In-Reply-To: <47F5106B.7080306 at lipn.univ-paris13.fr>
References: <47F5106B.7080306 at lipn.univ-paris13.fr>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: lablgtk at yquem.inria.fr, Jean-vincent.Loddo at lipn.univ-paris13.fr
Content-Type: Text/Plain; charset=us-ascii
Content-Length: 2780

Hi Luca,

The reason seems clear enough: threads in lablgtk rely on the use of a
special toplevel loop, defined in GtkThread.ml, which allows switching
to other ocaml threads between events. However, libglade probably
introduces its own loop for making dialogs modal, which blocks other
ocaml threads.
Actually, after a short check, the problem is not specific to
lablglade, it occurs when calling #run on any dialog.

A simple workaround is to add the following timeout:

let id =
  GMain.Timeout.add ~ms:100 ~callback:(fun () -> Thread.delay 0.001; true) in
let r = dialog#run () in
GMain.Timeout.remove id;
r

Actually, it should be ok to add such a timeout from the beginning,
and never remove it, and there would be no need for a custom main
loop (no conflict either).
The reason lablgtk uses a custom main loop is that it gives it a bit
more control on scheduling (no need to wait for a timeout when there
is nothing to do on the gtk side). Also, IIRC the above approach does not
work with VM threads (it is not possible to switch threads in
callbacks). But it works fine with machine threads (pthread or win32).

Jacques


From: Luca Saiu <Luca.Saiu@lipn.univ-paris13.fr>

> Hello.
> Sorry for bothering you with a possibly stupid question, but I really
> have no clue on this, while you might recognize my mistake.
> 
> We are working on a relatively complex OCaml application, Marionnet
> (http://www.marionnet.org), which uses lablgtk and lablglade with threads.
> 
> Scenario: we need the main application to communicate with an external
> daemon providing some services; we use Unix sockets. The daemon closes
> the socket to a client when it doesn't receive keep-alive messages often
> enough.
> 
> Our problem is this: *whenever* the main application is displaying a
> dialog built with Glade, the thread sending keepalives blocks and only
> unblocks after the window is closed. Of course this defeats the while
> purpose of keepalives.
> This does *not* happen with windows not built with Glade. I think it's
> extremely unlikely that this is a synchronization bug.
> 
> It would be possible for me to stop using keepalives and adopt a
> different strategy, but I would like to know if a clean solution exists;
> and I'm getting curious.
> 
> Do you have any idea of a possible cause of this problem? Ever heard of
> something similar?
> We use Debian packages for lablgtk, and OCaml 3.10.1.
> 
> Thanks in advance, and (especially) thanks for your nice software.
> 
> - --
> Luca Saiu
> http://www-lipn.univ-paris13.fr/~saiu
> GNU epsilon: http://www.gnu.org/software/epsilon
> Marionnet:   http://www.marionnet.org

_______________________________________________
Lablgtk mailing list
Lablgtk@yquem.inria.fr
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk