Quoting Julien Moutte: > > Hi it's me again :) > > So i m almost done with DirectFB videosink for GStreamer. I m doing a > stress test that's creating a window, giving the surface of that window > to gstreamer as a render target, and then resizing the window using a > sin () loop. > > Basically my GStreamer plugin locks the surface and draw data in the > data pointer. I'm wondering if this is safe because the other thread is > still resizing the window here and there. Does the surface lock function > actually lock the surface preventing window->Resize to modifying it > during that time ?
In general, all interfaces are not thread safe, except those that are meant to be used by multiple threads, i.e. IDirectFBEventBuffer and IDirectFBDataBuffer. The core itself should be thread safe. If you have multiple threads each having its own interface to a shared core object, it should be safe to have concurrent calls via the interfaces. If you want to use a single interface (instance) concurrently, you have to provide your own locking (except for the interfaces mentioned above). So in your case, you should be safe. But... locking the data portion of a surface currently doesn't prevent it from being reallocated. There has been a hard lock for this up to a certain version. It needs to be readded. The reason for taking it out was to support multiple concurrent locks (as in access to the data). You can simply try if it crashes with your great stress test. I guess it will crash due to accessing the data between the Lock() and Unlock() while reallocating (resizing) it from another thread. I'll fix it :) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
