On Thu, 2008-09-25 at 10:45 +0100, Neil Roberts wrote: > On Thu, 2008-09-25 at 09:16 +0100, Emmanuele Bassi wrote: > > and while GLib data structures and MainLoop are usually thread safe, > > GType instantiation is not entirely thread safe (try creating two new > > instances of the same class from the same thread). > > I don't think the threading issues are so much of a problem for this > simple case of calling glXSwapBuffers in a second thread.
sorry, I did not make myself clear enough - my bad, I still need the first coffee of the day. :-) what I meant was: pushing Clutter towards a heavier threads usage, in itself is a worthy goal at that, will require some serious rethinking of how the API should interact with threads. for instance, the BFL[1] we are using right now if you call clutter_threads_init() is far too big in granularity and will become an issue for internal and external usage soon enough. a potential extension would be using recursive locks instead of the current mutex by default - even though that creates some potential deadlocking which we'll need to consider. another option would be making every single clutter-specific data structure and usage inherently thread safe with internal locking - for instance, ClutterActor might have a lock and acquire/release the lock each time a property is changed; GStreamer objects do that and performance-wise they don't seem to suffer that much. yet another potential way to go would be threading up the COGL pipeline. ciao, Emmanuele. +++ [1] Big Fscking Lock -- Emmanuele Bassi, Intel Open Source Technology Center -- To unsubscribe send a mail to [EMAIL PROTECTED]
