Threads aren’t too well documented. 
I’m trying to load fonts and images in the background,
while the user is starting to use the app. (Tux Paint)
Versions and such: Linux 2.6, old-style threading,
libSDL from debian-unstable with “1.2.7-10” version,
libSDL_ttf “2.0.6-5”, gcc 3.4, 32-bit PowerPC,
glibc 2.2.5-11.5…
I looked over libSDL_ttf to check the source for being
thread-safe, and it looked pretty good. Calling the init
function in parallel would be bad, but I wouldn’t want
to do that anyway. Error handling goes via SDL_SetError,
which looks to be crash-proof as long as ‘%’ is not in
the error message – this is the case. Error messages
might get corrupted if DISABLE_THREADS was defined while
compiling libSDL (how to tell?), but oh well, no biggie.
Other than that, it looks OK. Did I miss anything?
Well, it doesn’t work so well, even just loading fonts.
(I haven’t gotten to backgound-loaded images yet.)
Sometimes my shell reports that Tux Paint was “Killed”.
Normally I’d only see this in a dire out-of-memory
situation. Another user reports SIGSEGV. Tux Paint is
more reliable when running under gdb. Just now I have
it running, but every “w” is replaced by a “_”. Another
time, I had every “o” replaced by a dark splatter.
I notice that the SDL thread package offers no way to
set the stack size. What does it use? Is there a guard
page on a thread stack?
BTW, you can grab Tux Paint from CVS now if you’d like
to try running it.