Re: Help: multithreaded GNOME app
- From: Owen Taylor <otaylor redhat com>
- To: Jason Tackaberry <tack dok org>
- Cc: "Marc J. Fraioli" <fraioli dg-rtp dg com>, Roland Dreier <droland mail math okstate edu>, gnome-list gnome org
- Subject: Re: Help: multithreaded GNOME app
- Date: 01 Feb 1999 19:15:34 -0500
Jason Tackaberry <tack@dok.org> writes:
> > The GTK thread (by which I assume you mean the thread that calls
> > gtk_main()) shouldn't ever block anywhere but inside of gtk_main(). If
> > you call pthread_cond_wait() from that thread somewhere, then it won't
>
> Yup, that is definitely not a working solution. :)
>
> > I think the basic strategy to follow is the one he is already
> > following; the GTK thread has one end of a pipe multiplexed in with the
> > other things it listens for in gtk_main(). The other thread or threads
> > send it notifications on that pipe, which indicate that it should look
>
> I think that's the best way to go about it too. (Thanks Jeff.) I'll pass
> a pointer to the data structure that's to be processed, instead of keeping
> a separate queue. (The pipe will be the queue for me.)
A rather elegant way of communicating with the main thread is:
g_idle_add (some_function, some_data);
Internally, GLib will use a pipe to wake the main thread out
of the select(), and then the main thread will execute
the function. If you do want to wait for remaining events
to be processed, then you should do:
g_idle_add_full (G_PRIORITY_HIGH, some_function, some_data, NULL);
some_function() should return FALSE so the idle is
executed only once.
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]