The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Is there a simple set of rules to follow when using SDL2 in an multi-threaded environment?

I ask because I am working on Go bindings for SDL2, and Go code is run in goroutines that jump between OS threads unless the goroutine has been locked to an OS thread.  So far this has caused some problems such as windows can only be created on the main OS thread on OS X, and events must be pumped on the same OS thread that created a window on Windows.


So I was just wondering if there is a simple set of rules to follow so code will be cross platform friendly.

I imagine the rules from 1.2 are still a reasonably good guide to go by:http://www.libsdl.org/docs/html/thread.html



~
Doug.


On Tue, Dec 11, 2012 at 9:41 AM, Jared Anderson wrote:

The thread that created the main window is the only thread that can
access it (including e.g. handling events). This is more of a
limitation of the underlying APIs, really (I recall the WinAPI imposes
this limitation, for instance).

Otherwise I can't think of any, locking aside.

2012/12/11 Doug:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Does anyone see any problems with the following setup, locking aside?

main thread used to create and interact with SDL_Windows, and call SDL_PumpEvents.
SDL_Renderers locked to a thread (one renderer per thread probably).
No other SDL calls locked to a thread.

The renderers make use of the GPU (Direct3D, OpenGL, etc.) which in
turn need access to the window, so renderer functionality needs to be
done in the same thread that created the window as well.

2012/12/11 Jared Anderson:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

In general the SDL APIs are not designed for thread safety.

The events API is explicitly thread-safe, and SDL provides the primitives you need to construct pretty much any synchronization primitive, but other than that if you call the same function on multiple threads you're likely to be asking for trouble.


This isn't because of any specific design decision, more because games tend to be careful about what work they do on different threads and it hasn't been a big issue.


Somebody is welcome to do an audit of the SDL code and propose changes where they are necessary and useful.


Cheers!

On Mon, Dec 10, 2012 at 5:41 PM, Jared Anderson wrote: