On Tue Jun 30 12:37:36 2026 +0000, Jacek Caban wrote:
My reading of the spec is that concurrent `glMapBuffer` calls will get you the buffer mapped in one thread and a well specified error in the other. I could imagine handling the error as part of a valid app logic. With this MR, it could crash or corrupt internal data instead. Well, I don't know. Reading the spec Chapter 5 "Shared Objects and Multiple Contexts" it just seems to me that everything is UB when accessing an object across shared context, unless client uses glFlush / glFinish / glFenceSync + glWaitSync to synchronize the changes externally, which makes sense to me.
I don't really mind about this code and my goal is mostly to get as much as possible out of the context, and I would be fine fine leaving the lock as it is, especially since it doesn't even seem to cause contention, but it also doesn't seem necessary to have such wide critical sections. Fwiw Mesa doesn't do any kind of locking in its MapBuffer / UnmapBuffer / BufferData / FlushMappedBufferRange implementation, and reads / writes multiple buffer object fields in a non atomic fashion. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11226#note_144539