You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Threads reading or writing to the same surface is something I can see happening easily. It's not inherently bad, but not the best practice or bad if they both write to it. Surface locking is not thread safe, so:
Add a SDL_mutex field in the surface object struct, that is created when the surface is created and is destroyed when it is freed
Create macros that when the python version is high enough and the gil is disabled lock the mutex before pixel access and unlock it after that
I know that atomic flags exist, but I'm not sure how reliable they are. If they are a better option we should use them.
pgSurface_Lock could also be made thread safe by making it a critical section.
Yeah it makes sense. SDL_Surface s created inside the functions cannot be modified by other threads anyways, only pygame surface objects so we can embed the mutex/atomic thread safety within that function. We "just" need to check how it is used right now and correct it if needed.
Thread safety is a big topic like SDL3 porting, so I think a github issue can be helpful to discuss it, as discord messages get lost quickly.
The text was updated successfully, but these errors were encountered: