search

ocsigen / lwt_glib

GLib/GTK event loop for Lwt
Other
11 stars 3 forks source link

Releasing OCaml runtime lock when calling g_main_context_dispatch #2

Open zoggy opened 6 years ago

zoggy commented 6 years ago

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.

aantron commented 6 years ago

@zoggy, I'm not very familiar with Glib at this point, but I assume callbacks run during g_main_context_dispatch. In that case, if there is code with callbacks that don't try to acquire the lock, that code would be broken by releasing it around g_main_context_dispatch. If that's accurate, we may need an optional argument to control the behavior.

I have a question related to performing Lwt I/O in callbacks. Are all your callbacks running in the main thread?

zoggy commented 6 years ago

Indeed we should have an optional argument to release or not the lock around g_main_context_dispatch.

My Gtk callbacks are running in the main thread indeed, because g_main_context_dispatch runs in the main thread. So by now I can use Lwt.async because most Gtk callbacks have side effects.

Libcef callbacks may be called in other threads (I have not traced the thread id yet).

aantron commented 6 years ago

Ok, I will be happy to review/merge any PRs on this or the other issue :)