On Sun, 13 Feb 2005 22:10:21 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote:

> Also tried to port the code to GThreadPool but it turned out to be not
> as trivial as I expected. The current code blocks until all threads
> are returned and it is not trivial to implement this behaviour with
> GThreadPool. So this part, the more interesting part of the TODO, is
> still open.
> I don't want to put more time into this, but I think it would
> definitely make sense to introduce a thread pool to cut down the
> number of thread creations. Any volunteers?

Here's a solution that would work:  (note, untested code, error
checking and unintersting stuff omitted for clarity, etc)

Calling code:
struct SynchStuff {
    GThreadPool *pool;
    GCond *cond;
    GMutex *mutex;
} synch;

typedef struct SynchStuff SynchStuff;

synch.cond = g_cond_new();
synch.mutex = g_mutex_new();

/* create an exclusive threadpool */
synch.pool = g_thread_pool_new(gimp_thread_func, &synch, ...); 

/* make sure that all the tasks are in the queue before checking if
queue is empty.


for (/* each task */ ...) {
    g_thread_pool_push(sych.pool, task, ....);

/* alll threads are now launched.  allow threads to test queue for emptiness
 * and wait for signal that all tasks are complete */

g_cond_wait (synch.cond, synch.mutex); 

/* all tasks are now complete */


void gimp_thread_func(GimpTaskData *task, SynchStuff *synch) {

  /* process task */

  /* wait until all tasks have been queued */

  if (g_thread_pool_get_num_threads(synch->pool) == 1)
      g_cond_signal(synch->cond, synch->mutex);


We could also try to talk the glib developers into including
g_thread_pool_join, which would block until the task pool is empty. 
It would be nice if the GThreadPool API were modelled on OpenMP to the
extent possible, which I admit is not really stellar because of the
compiler modifications OpenMP requires.  But perhaps some of what
OpenMP does with compiler modifications we can do with macros.

Gimp-developer mailing list

Reply via email to