On Mon, 2010-09-27 at 19:17 -0500, [email protected] wrote: > I'm working on a multithreaded application and found that calling > clutter_thread_enter twice, even from the same thread, locks up the > application.
quite rightly so: you're trying to acquire a mutex again. the default Clutter lock is done with a non-recursive mutex; you can override the default implementation on a per-application basis, and use a recursive mutex, but there are subtle deadlock scenarios down that road. > I tested this same scenario with GMutex and this is consistent. > If I'm very careful not to call clutter_thread_enter more than once > before calling leave, am I ok or is it a bad idea to have a > multithreaded application in clutter? multi-threading is perfectly fine. the only thing you should not *ever* do is to update the UI (i.e. call Clutter functions) from any thread that did not call clutter_init() and clutter_main(). the only Clutter API that is safe to call from within a thread is the clutter_threads_add_* API. the standard design for multi-threaded applications in Clutter is to spawn off worker threads that manipulate a shared state, and at the end of the long-running operation, call clutter_threads_add_idle() with a callback to update the UI. the callback installed by that function is guaranteed to be called from within the same thread that started the main loop, and under the Clutter lock. ciao, Emmanuele. -- Emmanuele Bassi, Open Source Software Engineer Intel Open Source Technology Center _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
