GBMDevice, and the gbm_device instance it wraps, can cause problems when managed on a thread-specific basis. gbm_bo objects created through these devices can be shipped or used across different threads, but it can also happen that the thread on which they were created through the GBMDevice/gbm_device specific to that thread is destroyed while gbm_bo objects live on. So the gbm_device is destroyed but the gbm_bo objects created through it live on, causing problems when the gbm_bo instance tries to use now-destroyed gbm_device for different operations. This is happening under certain circumstances inside GStreamer integration along with the swapchain object (bug #237238). Swapchain remains the same for the duration of the MediaPlayerPrivateGStreamer's lifetime. During the first playback, GStreamer's pipeline handles playback on one thread, spawning gbm_bo objects as required given that thread's GBMDevice. Once playback finishes, the pipeline will deconstruct these threads and the GBMDevice, which leaves the swapchain objects with a dangling gbm_device pointer. Mesa's libgbm is a useful wrapper along the specified DRI device file descriptor. I don't see possible thread-safety issues there, or at least have not experienced them so far working with that library. There's other implementations (closed-source too) that might not be so generous, but I would presume thread safety first. If things go sideways there's options of having a libgbm-specific thread where these allocations are performed, but the basis even before that would be a single per-process gbm_device.
<rdar://problem/90476889>
Created attachment 455083 [details] Patch
Comment on attachment 455083 [details] Patch LGTM!
Committed r291480 (248594@main): <https://commits.webkit.org/248594@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 455083 [details].