GNOME Bugzilla – Bug 782963
Make libgimp thread-safe
Last modified: 2017-08-16 10:14:27 UTC
Created attachment 352370 [details] [review] libgimp, libgimpbase: allow multi-threaded plugins by locking protocol calls. So since I am developping a plugin with intense computation, I need this to be in a thread to not block the GUI. I realized that libgimp* are not thread-safe at all! I had random errors like for instance: > expected tile ack and received: 5 The following patch makes it thread-safe. At least for what concurrency issues which I could find, which is a start. Basically the plugin protocol sometimes expects answers or acknowledgements, and we need to lock the communication channels temporarily so that to not have a thread run another command over the wire in the same time. Please find attached patch. :)
Does this simple patch works for your plug-in already?
(In reply to Joao S. O. Bueno from comment #1) > Does this simple patch works for your plug-in already? It does.
Pushed. We will now accept bug reports if people still experience multi-threading issues (maybe other calls need to be locked) or any noticeable slowdown. commit 15f73440388fb1c50957e4c3b5fb70e12c9311f2 Author: Jehan <jehan@girinstud.io> Date: Sun May 21 15:13:33 2017 +0200 libgimp, libgimpbase: allow multi-threaded plugins by locking... ...protocol calls. Some calls are waiting for answers, for instance plugin procedures, and tiles which expects data and acknoledgement. This would result in error messages such as: "expected tile ack and received: 5" (5 is GP_PROC_RUN) Typically because a thread would run a procedure while another would receive tiles. libgimp/gimp.c | 2 ++ libgimp/gimptile.c | 4 ++++ libgimpbase/gimpprotocol.c | 13 +++++++++++++ libgimpbase/gimpprotocol.h | 3 +++ 4 files changed, 22 insertions(+)