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.

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.)

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:



--
http://codebad.com/
_______________________________________________
SDL mailing list

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

On 5/18/10, bigfoot811 wrote:

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.

-Eric
_______________________________________________
SDL mailing list

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

On 18/05/2010, Eric Wing wrote:
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)
_______________________________________________
SDL mailing list

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

On 5/18/10, Kenneth Bull wrote:

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

-Eric
_______________________________________________
SDL mailing list

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

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:


--
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

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

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.

Alistair

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


_______________________________________________
SDL mailing list

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

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

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

>From: ""
>Subject: Re: [SDL] Running SDL in secondary 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.

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

my suggestion:
do any blocking operations on a secondary thread, and do ALL sdl stuff in the main thread.
This is necessary to maintain portability of the project without having to refactor again and again. ;)

and, as they said, it's bad practice to block the main thread...