Re: quetion about gtk_input_add()

[Tristan Van Berkom <vantr touchtunes com>]

ZHOU DX wrote:

> Hi,
>
> Thanks for that. But, I still have a few questions.
> Logic in the controller thread seems not quite right
> to me. I may have several childs, but the g_cond_wait
> will return when the first exits. So the harvest may
> only reap this first one. Am I wrong? 
> Also, I donot quite understand the g_thread_join part.
>  

My idea about a "controller" thread was that it would look kind of like 
this:

/***********************************/
while (controller_thread_should_run) {

   g_mutex_lock(death_mutex);
   g_cond_wait(death_cond, death_mutex);
   data = g_queue_pop_tail(death_data);
   /*
          Here you can use the data passed through the
          queue protected by death_mutex

           it would be wise to "reap" the dead thread with
           g_thread_join(data.thread).
    */
   g_mutex_unlock(death_mutex);  
}
/***********************************/

This way the controller waits on ONE cond and ONE mutex.
Children do something like this when they die:

/***********************************/
   data.thread = (GThread *)thread;
   data.joinable = TRUE;
   snprintf(data.message, MAX, "I'm dead!\n");

   g_mutex_lock(death_mutex);
   g_queue_push_head(death_data, data);
   g_cond_signal(death_cond);
   g_mutex_unlock(death_mutex);  
   return status;
/***********************************/

> The child has already gone after leave the message to
> the controller. So at that point, the controller may
> join nothing. Am I right?
No. If the child thread has returned, it is not a "zombie" so the
posix thread itself doesn't have to be "reaped"; but I dont see
the GThread object/structure itself ever getting free'd otherwise
(i.e. if you dont use joinable threads or dont call g_thread_join()).

> The reason why I ask this question is that I try to
> avoid updating/redrawing the GUI in a thread context.
> I dream that it would be nice if I can register a
> callback function to the main loop, which is called
> upon a "thread-exit" condition. (Like the idea of
> gtk_input_add.) What I can do now is to call
> "g_mutex_try_lock"  in an idle function (gtk_idle_add)
> to check a mutex that will be unlocked by a controller
> when all worker threads exit. It looks not quite nice
> though. 
>  
I see what you mean. You could use fifo's for that but it wouldn't
be entirly portable (by using GIOChannels). The lack of this feature:
   g_signal_connect(GThread *object, "exit", callback);
is probably due to some kind of lack of support on some platforms,
also, it would be a useless overhead for applications that aren't 
interrested
in "when a thread exits".

But I'm just shooting in the dark ;-)

Regards,
                                   -Tristan


<snip>