GNOME Bugzilla – Bug 542725
ThreadPool is unusable
Last modified: 2010-01-16 19:31:31 UTC
Please describe the problem: The threadpool is not currently usable due to the glib-2.0.vapi. I see initially two things that need to be fixed. 1) Cannot create a thread pool because of the constructor thinking it needs a user_data argument. 2) The free method takes 3 parameters, and the generated code only passes the threadpool. To fix the first problem, we can change the constructor to: [CCode (instance_pos = 1)] public ThreadPool (Func func, int max_threads, bool exclusive) throws ThreadError; Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
So we can also just make free an instance method and require that freeing be done explicitly. [CCode (free_function = "")] and public void free (bool immediate, bool wait_);
The constructor issue has been fixed in r1790, the free issue is still open.
Created attachment 144832 [details] A vala file that fails to compile Testcase that fails compilation $ valac --version Vala 0.7.7 $ valac threadpooltest.vala .... threadpooltest.vala.c: In function ‘_main’: threadpooltest.vala.c:39: error: too few arguments to function ‘g_thread_pool_free’
Created attachment 148300 [details] [review] Add special case for g_thread_pool_free, which takes 3 arguments. I'm not sure whether this should be called as g_thread_pool (foo, FALSE, TRUE) or g_thread_pool (foo, TRUE, TRUE). I went with the former, but it's trivial to switch to the latter. Docs are at http://library.gnome.org/devel/glib/stable/glib-Thread-Pools.html#g-thread-pool-free
Review of attachment 148300 [details] [review]: The GObject profile `if` statement breaks array handling.
commit 8630f4be0e5dcf749a60918700718b25e135786f Author: Jürg Billeter <j@bitron.ch> Date: Sat Jan 16 20:24:27 2010 +0100 Fix freeing ThreadPool Adds special case for g_thread_pool_free, which takes 3 arguments. Based on patch by Evan Nemerson, fixes bug 542725.