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>