Event handling and SDL -- specifically warnings against calling SDL_PumpEvents outside of SDL_SetVideoMode thread

SDL Development
1

I’m a bit confused about notes in SDL_PumpEvents, SDL_PollEvent, etc
regarding threading,

SDL_PumpEvents: http://www.libsdl.org/cgi/docwiki.cgi/SDL_PumpEvents

*Note: *You can only call this function in the thread that set the video
mode.

SDL_PollEvent: http://www.libsdl.org/cgi/docwiki.cgi/SDL_PollEvent

As this function implicitly calls SDL_PumpEventshttp://www.libsdl.org/cgi/docwiki.cgi/SDL_PumpEvents,
you can only call this function in the thread that set the video mode.

SDL_PollEvent http://www.libsdl.org/cgi/docwiki.cgi/SDL_PushEvent

This function is thread safe, and can be called from other threads safely.

It is not clear why this note is there. Possibilities include:

  1. SDL doesn’t use Posix threads so the queues are in different memory
    segments not shared/accessible across the threads
    Evidence against: SDL source includes pthread references,
    Evidence for: but it not exactly clear which platforms use pthreads

  2. SDL doesn’t have thread mutexs around the SDL_PumpEvents, and
    SDL_PollEvents, but SDL_PushEvents is wrapped in mutexs
    Evidence for: SDL_PumpEvents, SDL_PollEvents, SDL_PushEvents have no mutexes
    but they all call SDL_PeepEvents
    Evidence against: SDL_PeepEvents has mutexs

So, neither of the above seem to answer my question. The "important"
rountne SDL_PeepEvents seems to be thread safe, pthreads is used, so why the
warning against initializing the video in one thread and grabbing events in
another?

-Jason–
Jason Harrison, PhD
Software Development
Human-Computer Interaction
Project Management

Cell: 604 644 8611
Email: @Jason_Harrison

Thanks to Yggy King for bringing this quote to my attention:
Thinking the world should entertain you leads to boredom and sloth. Thinking
you should entertain the world leads to bright clothes, odd graffiti and
amazing grace in running for the bus. – Ann Herbert

2

Okay, found the answer to my own question:
http://www.libsdl.org/cgi/docwiki.cgi/SDL_CreateThread

(SDL 1.2.9) On win32 (this wasn’t observed on unix), the initial thread must

be the one polling the SDL events. Otherwise, keyboard events are no longer
caught. Moreover, it is recommended to use SDL_mixer and SDL blitting
functions from within that initial thread as well, otherwise the system
becomes unstable (also only under win32) despite the proper use of mutexes
and conditional variables. This unfortunately limits a lot the usefulness of
threads when the software is also expected to run on win32.

Has anyone looked into this?

-JasonOn Mon, Oct 27, 2008 at 11:36 AM, Jason Harrison <@Jason_Harrison>wrote:

I’m a bit confused about notes in SDL_PumpEvents, SDL_PollEvent, etc
regarding threading,

SDL_PumpEvents: http://www.libsdl.org/cgi/docwiki.cgi/SDL_PumpEvents

*Note: *You can only call this function in the thread that set the video
mode.

SDL_PollEvent: http://www.libsdl.org/cgi/docwiki.cgi/SDL_PollEvent

As this function implicitly calls SDL_PumpEventshttp://www.libsdl.org/cgi/docwiki.cgi/SDL_PumpEvents,
you can only call this function in the thread that set the video mode.

SDL_PollEvent http://www.libsdl.org/cgi/docwiki.cgi/SDL_PushEvent

This function is thread safe, and can be called from other threads
safely.

It is not clear why this note is there. Possibilities include:

  1. SDL doesn’t use Posix threads so the queues are in different memory
    segments not shared/accessible across the threads
    Evidence against: SDL source includes pthread references,
    Evidence for: but it not exactly clear which platforms use pthreads

  2. SDL doesn’t have thread mutexs around the SDL_PumpEvents, and
    SDL_PollEvents, but SDL_PushEvents is wrapped in mutexs
    Evidence for: SDL_PumpEvents, SDL_PollEvents, SDL_PushEvents have no
    mutexes but they all call SDL_PeepEvents
    Evidence against: SDL_PeepEvents has mutexs

So, neither of the above seem to answer my question. The "important"
rountne SDL_PeepEvents seems to be thread safe, pthreads is used, so why the
warning against initializing the video in one thread and grabbing events in
another?

-Jason

Jason Harrison, PhD
Software Development
Human-Computer Interaction
Project Management

Cell: 604 644 8611
Email: @Jason_Harrison

Thanks to Yggy King for bringing this quote to my attention:
Thinking the world should entertain you leads to boredom and sloth.
Thinking you should entertain the world leads to bright clothes, odd
graffiti and amazing grace in running for the bus. – Ann Herbert

–
Jason Harrison, PhD
Software Development
Human-Computer Interaction
Project Management

Cell: 604 644 8611
Email: @Jason_Harrison

Thanks to Yggy King for bringing this quote to my attention:
Thinking the world should entertain you leads to boredom and sloth. Thinking
you should entertain the world leads to bright clothes, odd graffiti and
amazing grace in running for the bus. – Ann Herbert

3

Has anyone looked into this?

Usually the problem isn’t that SDL isn’t thread-safe. The problem is
usually that the platform’s API isn’t.

SDL_PushEvent() is thread safe, and so is SDL_PeepEvents(), because both
work entirely within SDL and have mutexes around them.

SDL_PumpEvents() has to talk to the platform’s APIs, so all bets are off
there, even though it eventually moves events from the platform’s API
into the thread-safe SDL queue, that SDL_PeepEvents() retrieves them from.

Fwiw, Windows is not the only platform that has this problem. Almost all
platforms SDL supports, including Mac OS X and most Unixes, suffer from
it, too, in some form. Keep all the window manager stuff in one thread,
preferably the same thread as main().

It’s not something we can fix, as it’s not SDL’s fault.

–ryan.