[SDL] What are threads allowed to do?

Doodle doodle at scenergy.dfmk.hu
Fri Jan 21 01:09:20 PST 2005

On Fri, 21 Jan 2005 16:50:19 +0800, Eric Vidal wrote:

>I may be wrong, but I think the only reason for the "don't call library 
>functions in separate threads" is because some of those library 
>functions change an implicit "state" in SDL's own space, such that a 
>program may enter and exit that state only through the same thread.

I think that there is another problem, too, which is a design problem,
in my opinion. I've faced it when I was working on the OS/2 port of SDL.

The problem does not exist when SDL is statically linked to the executable,
because in that case both SDL and the application uses the very same
C runtime library. In that case, it's safe to use runtime library functions from
other threads.

However, once the application uses SDL dynamically linked (in a form
of a DLL), the following problem arises:

The SDL DLL uses its own C runtime library, let's say, the RTL of OpenWatcom
(if it was compiled with OpenWatcom).
When an executable, which is compiled with a different compiler (e.g. GCC),
calls into the DLL to create a new thread (SDL_CreateThread), that new thread
will be created by the RTL of OpenWatcom, and the RTL of the executable
will not be initialized for that new thread.
So, it's unpredictable what will happen if the application calls its own runtime 
library functions from that thread (well, I had crashes).

This problem might not exist on other platforms, because
Windows and Linux usually uses common runtime libraries, so even though 
SDL is in a separate DLL/shared object, the RTL calls will go to the same
runtime library at the very end.


More information about the SDL mailing list