Delivered-To: garrigue at math.nagoya-u.ac.jp
Authentication-Results: mailhost.math.nagoya-u.ac.jp sender=lablgtk-bounces at yquem.inria.fr; domainkey=neutral (domain does not match address; no policy for yquem.inria.fr)
Delivered-To: lablgtk at yquem.inria.fr
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h=
	date:message-id:to:cc:subject:from:in-reply-to:references
	:mime-version:content-type:content-transfer-encoding; s=alpha;
	bh=WS1XGRVWSc14U3SmUsG+gpNXZ9s=; b=ohX3UbWLftudZXzJQfszXIOmZP9H
	lsV/o+nCcpha4SZF3+qT0UabnWLn+zF1eB6rgHNO+vyL5YD8s2Bm2XXyI5mPjsmg
	IJypCsBTMZjQ2wnjr3GcYIC6GZnu4d0FzQXc0ztiIDtjLWznMHtquca48Yl318u/
	sWuUWt7hTgf6OqU=
DomainKey-Signature: a=rsa-sha1;
	h=Received:Date:Message-Id:To:Cc:Subject:From:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding;
	b=o6erkpvCkEAxqaZBKDxzDb8NZoAfpedSYT0cRT43Jf2V9D1+wJFNZu2TrUnxsgg9TRrTzhTiwTMalGDvPJOxuQrjIMvWqE285HKa60otloMDkoGG2w5iKjO1FeWR0P9KcRJElHz39Cjroz8HFeG4LPY+OGqh/Y3pP4F+IKsf3i0=;
	c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha
Date: Fri, 25 Jun 2010 19:04:37 +0900 (JST)
Message-Id: <20100625.190437.58776423.garrigue at math.nagoya-u.ac.jp>
To: rich at annexia.org
Subject: Re: [PATCH] Re: [Lablgtk] dialog#run seems to block other threads
From: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
In-Reply-To: <20100622175338.GB6495 at annexia.org>
References: <20100622170649.GA6495 at annexia.org>
	<20100622175338.GB6495@annexia.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: lablgtk at yquem.inria.fr
Status: U

Hi,

Basically, the strategy for threading in lablgtk is to roll out
our own main loop, in ocaml, so that we can switch without doing
anything on the C-side. In particular, it avoids having to do tricky
things with callbacks, or when touching ML data structures from the
C-side.
But gtk_dialog_run creates its own main loop, and does not return, so
there is no chance for switching threads on the caml side.

Something that seems to work is to add the following timeout:
  GMain.Timeout.add ~ms:100 ~callback:(fun () -> Thread.delay 0.001; true);
If you do that, thread switching will occur even when a dialog runs.

The reason this is not the default implementation is that it does not
work with vm threads, which cannot switch threads in callbacks.

For your problem with sync/async calls not getting executed, I added a
function GtkThread.do_jobs, so that you just have to write:
  GMain.Timeout.add ~ms:100 ~callback:GtkThread.do_jobs

By the way, your patch is clearly wrong: gtk_dialog_run may call some
callbacks (it usually does), and it will do so without reclaiming the
lock.

Jacques

From: Richard Jones <rich@annexia.org>
> I looked at the lablgtk2 source and I can see the problem.  The
> wrapper for dialog#run doesn't even attempt to release the OCaml GC
> lock.
> 
> I have applied the following patch to my local copy, which appears to
> cure the problem for me.  I don't know if it is safe to release the
> lock at this point, perhaps someone who knows the code a bit better
> could comment.
> 
> Unless I'm doing it wrong, I don't see any calls to
> caml_enter_blocking_section in the whole of the lablgtk2 code base ...
> 
> Rich.
> 
> -- 
> Richard Jones
> Red Hat

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