Re: [PATCH] Re: dialog#run seems to block other threads

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 <[email protected]>
> 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