> However back to my code: > pool = g_thread_pool_new( my_calc, (gpointer) &common, 8, FALSE, &err ); > > for (i = 0; i < n_tot; i++ ) > g_thread_pool_push( pool, &store[i], &err ); > > g_thread_pool_free( pool, FALSE, TRUE ); > > Why doesn't the g_thread_pool_free function stop and wait for all > threads. I really specify this to wait (the third parameter is wait_ > and set TRUE). In my understanding this must then be a bug in glib. > Should I fill in a bug report? Oh my! What a blunder. I got the parameters in my_calc() swapped. It then just returned without calculating anything. I fixed this, and it now seems to work. The documentation on this is a bit unclear, and may need some polishing, but there is no bug. Scaling is a bit strange though! I'm working on a box with 2 intel xeon quad core processors and would therefore expect to get a close linear speed up from 1 -8 threads. Here's the results: Threads execution time [sec] 1 14.38 2 11.73 3 7.59 4 6.42 5 5.89 6 14.91 7 33.94 8 35.00 Is it the mutex lock and unlock that gives all this overhead when there's many threads. I'll try splitting the array and see if that gives better scalability. -Øystein _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
