On Wed, 08 Jul 2009 01:52:42 -0700 Terrence Cole <terrence@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2009-07-08 at 07:42 +0300, Dov Grobgeld wrote: > > That indeed is a more elegant solution! I really feel that I'm > > learning one step at a time... Regarding the use of > > g_atomic_int_..., I'm curious how you fit his into the flow? > > Obviously T and G must be initialized to share a stopping variable > > s. Who should create this variable? I would be interested to see > > how you would amend your 1-direction solution so that it also > > supports stopping. > > A common pattern for simple background tasks that spit out a lot of > intermidiate data (with most of the tedious init, casting, cleanup, > error detection, and being compilable missing) could look something > like this: [snip] If the GAsyncQueue object is used only for passing data to an idle handler, you can in fact dispense with the queue and pass the data as the data argument of g_idle_add()/g_idle_add_full(). This is because the main loop is thread safe and locks and unlocks a mutex when the idle handler and its data is passed to the main loop's own queue object, and when again it is popped off for dispatch. As there will have been a release operation on the main loop's mutex after the handler is loaded into the main loop and an acquire operation on the same synchronization object when it is popped off for dispatch, memory visibility between threads will be guaranteed. As in the case of your GAsyncQueue example, you will need to allocate the data on the heap and free it in the idle handler when finished with. Chris _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
