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.
On Tue, Dec 11, 2012 at 9:41 AM, Jared Anderson wrote:
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.
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 <douglas.linder at gmail.com>:> I imagine the rules from 1.2 are still a reasonably good guide to go by:
On Tue, Dec 11, 2012 at 9:41 AM, Jared Anderson wrote:
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.
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 :> 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.
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:
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.