Since g_main_context_dispatch is called in the main Lwt thread, the callbacks associated to Gtk events cannot call Lwt functions. Do you think it would be possible to call this function in a detached thread (using Lwt_preemptive.detach), so that callbacks could call Lwt_preemptive.run_in_main ? It may not be wishable for all applications, so this would have to be optional. And I don't know if Glib would be happy with this.

Hi,

Consider this piece of code (using lwt_ppx syntax) :

let tests () =
   Printf.printf "Before sleep.\n%!" ;
   let%lwt () = Lwt_unix.sleep 0.5 in
   Printf.printf "After sleep.\n%!" ;
   Lwt.return_unit

• It behaves as expected in a stand-alone lwt program.
• It behaves as expected in a lablgtk program, using lwt_glib, when invoked outside of a gtk callback.
• However, it hangs when used inside a gtk callback. Let us give some details :

In order to use lwt code within a gtk callback, I use the (supposedly) canonical way to do this:

let cb _ =
    let () = Lwt.async tests in
    true

This callback is used, for instance, on an event_box (called 'zone') :

let _ = zone#event#connect#button_release ~callback:cb

Then, I observe the following behaviour:
If I click in the zone (only click, the mouse must not move), the message "Before sleep" is printed. It hangs undefinitely, until I move the mouse (which generates a gtk event). Then, the message "After sleep" is displayed.

In short : Lwt_unix.sleep hangs until some arbitrary gtk event occurs.

Note that if you use a button instead of an event box, the button generates at least one event after it has been clicked (most likely to redraw itself), hence the lwt_unix.sleep does not block

A quick fix consists in adding a gtk timer :

let _ = GMain.Timeout.add ~ms:100 ~callback:(fun () -> true)

..but this is not really satisfactory.

Here is a zip exposing the bug. Requires dune, lablgtk, lwt_glib. Type 'make'.

(github does not support .tgz ??????)

Lwt_hangs.zip

I'm currently developing a proof of concept application, using Chromium Embedded Library (libcef) and Gtk3 bindings.

Libcef runs various threads and takes callbacks. Some of these callbacks are OCaml functions in my application. So the code of these callbacks can be called at any moment (depending on what the browser wants to load, etc.). So for every call to libcef C function, I release the OCaml runtime lock and my callbacks acquire it. To do so, I use Ctypes and the runtime_lock argument of Foreign.foreign and foreign.funptr.

Now comes the moment when I want to handle Gtk events. I use my own bindings (not published yet, under development). In these bindings, the OCaml callbacks associated to Gtk events also acquire the runtime lock and release it after, and every C function call releases the OCaml runtime lock too, so that everything is fine with the libcef threads.

In some of the Cef and Gtk callbacks, I want to perform IO, using Lwt. I found Lwt_glib which is great, thank you ! I use the glib_into_lwt mode but it blocks. To make it work, I had to release the runtime lock when calling g_main_context_dispatch function, so that my callbacks can acquire the lock. I can make a pull request, but wanted to be sure it would be ok for other code not releasing the ocaml runtime lock (I think so).

By the way, using the lwt_into_glib mode does not work in my case, but I did not find why yet.