On Mon, 5 Jan 2009 11:15:18 +0000 jcupitt@xxxxxxxxx wrote: Thanks, John, > I think you have this backwards for glib. > > You can't really do anything time critical in the main loop. All it's > there for is repainting the screen and responding to messages from > widgets. Any real-time stuff has to be in worker threads and they > can't (usually) do anthing to the GUI. They need to send messages to > the main thread when they want the display updated. It's not really that time critical nor actually real-time; nothing will break for a delay of a few ms and granularity is essentially a few ms. g_main_loop() is working fine for that, also because it simplifies mixing many different types of events. But the secondary tasks can take several seconds up to minutes (but it also can be fast) depending on factors which can't be controlled ahead of time. So I needed to separate these two things. But I forgot to mention, that this is not a gtk or gdk but only a glib program, without GUI or user interaction. I think, I'll stick to the solution using pipes, as it's starting to work. But it would be nice, if g_main_loop() had some magic to wait for a blocking mutex as does poll() waiting for a file descriptor becoming read or writable. Unfortunately, polling such a mutex with trylock over some time interval isn't an option in this case, as the overhead would be too big. Thanks, -- Chris _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
