GNOME Bugzilla – Bug 746262
Should be able to stop a GLib.ThreadPool
Last modified: 2015-03-18 15:47:51 UTC
We have code that uses a GLib.ThreadPool to perform an asynchronous operation (bug #736773), and want to make the operation cancellable using GLib.Cancellable. But once we detect that the Cancellable has been canceled, we have no way to stop the ThreadPool from performing more work! In C this is done using a call like g_thread_pool_free (pool, TRUE, FALSE), which also frees the pool. The destructor is hardcoded in valaccodebasemodule.vala (bug #542725) to always be called as g_thread_pool_free (pool, FALSE, TRUE), which was probably good choice. But drat! I'm not really sure how to handle this well. I guess a method ThreadPool.stop that invokes g_thread_pool_free with the second parameter FALSE, but that would require a huge warning that such ThreadPools should be nullable and carefully checked to be sure it's not null... probably not the way to go. I imagine this is an issue for other language bindings too, so I checked Python GI, which just exposes free as-is. That's probably the right thing to do: it's obvious enough that programmers should be careful when calling a method named free....
I think here the easiest way is using a static method wrapper with a pointer to the variable, which calls free() and then nullify the variable. For vala devs: The more correct way instead is to add a free() method with [DestroysInstance], however this is a little problematic in the compiler atm, unfortunately. With reference-counted objects, it works fine because a ref is done, but with compact classes the reference must be transferred.
Created attachment 299698 [details] [review] add ThreadPool.free Use like this: ThreadPool.free ((owned) tp, true, false); Does this solve your problem?
Yes, that patch works for me. Thanks!
commit 476247f68c6c2fba4043759e9caebc917e49d951 Author: Luca Bruno <lucabru@src.gnome.org> Date: Wed Mar 18 12:06:59 2015 +0100 glib-2.0: provide access to original ThreadPool.free() Fixes bug 746262 This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.