Running SDL in secondary thread

SDL Development
1

I have a main thread which conditionally blocks, so I need to run my SDL app in a secondary thread. In the run() of the secondary thread, I put my SDL init, video initialization and event loop which also does a render. I pause 100 milliseconds in each iteration. The OpenGL graphics seems to display fine, but I am not receiving any mouse or keyboard events from the window

This is my first application using SDL, so I am not sure if there is any special consideration needed for running in a secondary thread. If I put my same SDL code into the main thread, everything works fine.
Could someone give me a pointer or two on how to solve this problem?

Thanks for any help
(I am using Snow Leopard and SDL 1.3.)

2

I don’t think this use case is supported. At least some time ago it
was not. The main thread on some systems, at least in the past, was
special for some purposes, and some things probably won’t work. Maybe
a different SDL video back-end will produce different results?On Tue, May 18, 2010 at 4:29 PM, bigfoot811 wrote:

I have a main thread which conditionally blocks, so I need to run my SDL app
in a secondary thread. In the run() of the secondary thread, I put my SDL
init, video initialization and event loop which also does a render. I pause
100 milliseconds in each iteration. The OpenGL graphics seems to display
fine, but I am not receiving any mouse or keyboard events from the window

This is my first application using SDL, so I am not sure if there is any
special consideration needed for running in a secondary thread. If I put my
same SDL code into the main thread, everything works fine.
Could someone give me a pointer or two on how to solve this problem?

Thanks for any help
(I am using Snow Leopard and SDL 1.3.)

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
http://codebad.com/

3

Particularly since you run on OS X, this is probably not well
supported. The problem is that a lot of things in Cocoa are not thread
safe (true of both Mac and iPhone). Since SDL is written on top of
them, you are susceptible to the problems. Generally speaking, on OS
X, anything that is in AppKit or UIKit (the GUI layers of Cocoa) are
not thread safe and must be done on the main thread. This includes
stuff like events, windows, drawing in views, etc.

However, lower layers of OS X can be done in background threads, such
as drawing in Quartz 2D or OpenGL. Since SDL insulates you from Quartz
and AppKit/UIKit, you won’t know which is being used so you should
generally avoid non-OpenGL drawing in your app on background threads.

So generally speaking, if you want to use threading, you’ll need to
factor your code in such a way that the unsafe things are always
performed on the main thread.

-EricOn 5/18/10, bigfoot811 wrote:

I have a main thread which conditionally blocks, so I need to run my SDL app
in a secondary thread. In the run() of the secondary thread, I put my SDL
init, video initialization and event loop which also does a render. I pause
100 milliseconds in each iteration. The OpenGL graphics seems to display
fine, but I am not receiving any mouse or keyboard events from the window

This is my first application using SDL, so I am not sure if there is any
special consideration needed for running in a secondary thread. If I put my
same SDL code into the main thread, everything works fine.
Could someone give me a pointer or two on how to solve this problem?

Thanks for any help
(I am using Snow Leopard and SDL 1.3.)

4

Not the main thread necessarily, but the same thread. Basically, you
can’t run your event loop in a different thread than the one you
created your windows in if you want it to work. (Same for Windows,
though for other reasons)On 18/05/2010, Eric Wing wrote:

So generally speaking, if you want to use threading, you’ll need to
factor your code in such a way that the unsafe things are always
performed on the main thread.

5

No, on OS X, are areas that must be done on the main thread.

-EricOn 5/18/10, Kenneth Bull wrote:

On 18/05/2010, Eric Wing <@Eric_Wing> wrote:

So generally speaking, if you want to use threading, you’ll need to
factor your code in such a way that the unsafe things are always
performed on the main thread.

Not the main thread necessarily, but the same thread. Basically, you
can’t run your event loop in a different thread than the one you
created your windows in if you want it to work. (Same for Windows,
though for other reasons)

6

In general, you never want to run a second thread on OSX for anything to do with Cocoa, Cocoa is not thread safe and very prone to crashing if you are not careful, I ran into many issues on QuakeLive
with this approach (which does use a second thread for the game window).

Not a single Cocoa function is thread-safe, so you must use mutex blocking around all Cocoa calls, even closing a window will crash if other Cocoa calls are occurring.

To understand why, read up on the event loop and memory pools, but here’s the basic concept: there is a “memory pool” which groups allocations for easy freeing all at once, the main event loop empties
this pool every iteration to get rid of stale event processing data, so if something is still using that data in another thread you get a crash, intriguingly most of the window management functions
also allocate from this pool so if it is freed during their use, you get a crash…

So you have to block the main thread whenever you call Cocoa functions from your secondary thread…

It’s fairly painful.

X11 can accommodate threaded calls but you have to call a function to enable threading I believe, but be aware that the events come in on the event loop thread, so your event handling will be running
on that thread, and thus you need some blocking to keep that from messing up your other thread.

Windows accommodates threaded calls by default, but be aware that your events come in on the event handling thread (same considerations as above).On 05/18/2010 01:29 PM, bigfoot811 wrote:

I have a main thread which conditionally blocks, so I need to run my SDL
app in a secondary thread. In the run() of the secondary thread, I put
my SDL init, video initialization and event loop which also does a
render. I pause 100 milliseconds in each iteration. The OpenGL graphics
seems to display fine, but I am not receiving any mouse or keyboard
events from the window

This is my first application using SDL, so I am not sure if there is any
special consideration needed for running in a secondary thread. If I put
my same SDL code into the main thread, everything works fine.
Could someone give me a pointer or two on how to solve this problem?

Thanks for any help
(I am using Snow Leopard and SDL 1.3.)

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

7

Hi Forest-

Are you referring to NSAutoreleasePool? Each thread does maintain its own pool (see Apple’s docs) - retain/release are atomic, too.

Whilst AppKit isn’t exactly thread-friendly, Foundation (the other half of Cocoa) is perfectly happy to be multi-threaded, hence the built-in mechanisms like NSThread and friends. As long as you do UI processing on the main thread (doable easily with performSelectorOnMainThread:withObject:waitUntilDone:), you should be fine.

AlistairOn 19 May 2010, at 09:17, Forest Hale wrote:

In general, you never want to run a second thread on OSX for anything to do with Cocoa, Cocoa is not thread safe and very prone to crashing if you are not careful, I ran into many issues on QuakeLive
with this approach (which does use a second thread for the game window).

Not a single Cocoa function is thread-safe, so you must use mutex blocking around all Cocoa calls, even closing a window will crash if other Cocoa calls are occurring.

To understand why, read up on the event loop and memory pools, but here’s the basic concept: there is a “memory pool” which groups allocations for easy freeing all at once, the main event loop empties
this pool every iteration to get rid of stale event processing data, so if something is still using that data in another thread you get a crash, intriguingly most of the window management functions
also allocate from this pool so if it is freed during their use, you get a crash…

So you have to block the main thread whenever you call Cocoa functions from your secondary thread…

It’s fairly painful.

X11 can accommodate threaded calls but you have to call a function to enable threading I believe, but be aware that the events come in on the event loop thread, so your event handling will be running
on that thread, and thus you need some blocking to keep that from messing up your other thread.

Windows accommodates threaded calls by default, but be aware that your events come in on the event handling thread (same considerations as above).

On 05/18/2010 01:29 PM, bigfoot811 wrote:

I have a main thread which conditionally blocks, so I need to run my SDL
app in a secondary thread. In the run() of the secondary thread, I put
my SDL init, video initialization and event loop which also does a
render. I pause 100 milliseconds in each iteration. The OpenGL graphics
seems to display fine, but I am not receiving any mouse or keyboard
events from the window

This is my first application using SDL, so I am not sure if there is any
special consideration needed for running in a secondary thread. If I put
my same SDL code into the main thread, everything works fine.
Could someone give me a pointer or two on how to solve this problem?

Thanks for any help
(I am using Snow Leopard and SDL 1.3.)

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

I have a main thread which conditionally blocks, so I need to run my SDL app in a secondary thread.

why does the main thread need to conditionally block, and what is
blocking? perhaps that should be worker thread ?

9

I have a main thread which conditionally blocks, so I need to run my SDL app in a secondary thread.

why does the main thread need to conditionally block, and what is blocking? perhaps that should be worker thread ?

Yeah. That’s what I thought when I saw this. You should never block your main thread for any significant amount of time if you can avoid it.>From: “mattmatteh at gmail.com”

Subject: Re: [SDL] Running SDL in secondary thread

10

Thanks everyone for the expert help. We are refactoring so that our event loop can be in the main thread.