Message-ID:
? ? ? ?<AANLkTinH6uuZq6DECTxKv0Y37e1+c-_wPFYBq4-z7knj at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1It would be better to just include a note in the current threading
documentation that you should not expect to be able to create a window,
render, or recieve events on any thread other than the main one. That covers
everything.A mention of which operating system (Windows…) this restriction
applies to might be nice. ?Also, as I understand it, it is not
necessarily the main thread, but merely the same thread that SDL video
is initialized from (using SDL_Init, SDL_InitSubSystem, or
SDL_VideoInit).
I remember posting several times that it IS NOT WINDOWS that does
this, but MAC OS X. In fact, here’s a link:
http://www.dribin.org/dave/blog/archives/2009/02/01/main_thread_apis/
Here’s another link (scroll down to Window Restrictions):
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html
The gist of it is: Mac OS X requires all user interface behavior to be
implemented through the main thread, and if you try to directly work
around that, it apparently pauses the thread you tried to use while
the main thread deals with what you requested. OpenGL might be
different, but this is the way that the actual Mac OS X api seems to
work (according to their own documentation, none the less).
Windows requires you to do all operations on a window in the same
thread that created the window, but that’s apparently all.
In short: this is NOT a Windows issue, it is a “everything except for
X Windows, and then just because it buffers your requests” issue. It
has little to nothing to do with which thread the video for SDL was
initialized from. Take the time to read up.
Additionally, because SDL is primarily a cross-platform library, any
time that you find yourself wondering whether you can do something on
one platform that you can’t do on another, you should reconsider
whether you should do it at all.
It’s also possible to remove this restriction if someone’s willing to
work on it.
You’re free to volunteer yourself for the job. Another post today said
that the SDL software renderer was itself implemented through the SDL
api, so it should be possible to adapt that into a form that can
marshal SDL calls from one thread to another.
If you aren’t willing to do it yourself, then you shouldn’t bet
anything on it being done. Individual people will inevitably have
different perspectives on which features are more important than
others, but the ones who actually do the work are the ones who
actually get to decide. Also, it could be a valuable learning
experience.
I’ve done some stuff vaguely reminiscent of this before (a failed MMO
project), so if you need someone to bounce ideas off of then I can
help, but this feature isn’t anywhere on my horizon, so I won’t be
working on it myself.> Date: Thu, 20 Jan 2011 21:52:19 -0500
From: Kenneth Bull
To: sdl at lists.libsdl.org
Subject: Re: [SDL] A message on threading documentation
On 20 January 2011 11:38, Nathaniel J Fries wrote: