On Tue, 2007-07-10 at 17:44 +0200, Gabriele Greco wrote: > I've a few threads (more than one) doing some work (not accessing GTK > functions), I'd like to have a general way to make them notify their > work to the main loop. > > I used the g_idle_add() in the previous context where I had only a > thread with this behaviour, but with two or more threads the > g_idle_add() method of notification is not correct IMHO (what happens if > two threads call g_idle_add() before the call of the first one is > processed by the glib main loop?) > > I thought about a mutex solution, something like this: > > thread X: > lock idle_mutex > g_idle_add(my_idle_func) > > my_idle_func: > unlock idle_mutex > [update the gui] > return FALSE > > This way should work but when I use mutexes in context I've not full > control on I always fear unhandled deadlock situations... > > I though about using a GAsyncQueue for every thread but in this way the > problem I have is how to notify the main loop that there is something on > a queue, I've not found anything in the documentation... I fear the only > way it's to use a pipe or a socket, or an idle function, but in this > case I will occur again in the locking problem, I hope I'm wrong about > this so I'm asking here :)
If you were on a unix/linux box, I'd suggest writing to a pipe. It allows multiple writers and one reader, and you can make a select call in a g_idle_add() callback to see if it's readable and handle it if so.* I haven't experienced a locking problem with regard to writing to a pipe or socket. Multiple threads can be writing to a pipe, but each chunk passed is guaranteed to be written intact, and you've only got one reader, so no contention problem on that end. As long as you always know how much a writer has sent you (a length field in a fixed-size header, or fixed-size messages). And if all readers and writers are in the same address space, they only need to pass the address of the object, so you are writing just pointers, and using ring buffers, right? // Wally *Let me add that I would first take a closer look at what gtk provides that's more processor efficient than an idle-loop for checking whether something is readable. -- [EMAIL PROTECTED] Office: 619.278.2084 Cell: 619.990.2286 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
