On Mon, 10 Aug 2009 07:12:53 -0700 (PDT) puzzlecracker <vehomzzz@xxxxxxxxx> wrote: > Using g_idle_add() implies some pretty important things about event > processing priority that are not implied by the OP. > > Priority is fairly high. Do I call _idle_add() from a separate > thread? It doesn't imply anything. With g_idle_add_full() you can choose any priority you like, including G_PRIORITY_HIGH which will put it ahead of anything else in the event queue, including any GDK drawing operations (which is not a good idea so I do not recommend that). g_idle_add()/g_idle_add_full() do exactly what you are trying to do in long hand, but correctly. In unix-like operating systems they use a pipe. In Windows they use a windows event object. All the glib event loop operations are thread safe provided you have called g_thread_init(). You are also guaranteed memory visibility as regards the data argument of g_idle_add() and g_idle_add_full*(). This is because the main loop has a mutex protecting its event queue. Adding a new event with g_idle_add() will lock and unlock the mutex. The dispatching of the event in the main GUI thread will do the same. You will therefore, at the time of dispatch, have had a release operation on a synchronisation object by the thread posting the event, and an acquire operation on the same synchronisation object by the thread dispatching it. POSIX and windows both require cache synchronisation in that case. Yes, you call g_idle_add()/g_idle_add_full() in the thread wanting to post an event, and it will execute in the main GUI thread. Chris _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
