Taking a shot in the dark here… Since no one can know what you know we
have to take shots in the dark.
Yeah, I know. Thank you for trying.
On linux, the C/C++ standard libraries may or may not be thread safe, it
all depends on the version you use. If you are on 3.0 or better then the
standard libraries are thread safe (at least that is what the docs I
have found say and it seems to work).
This is plain C, not C++. I have various gcc versions from 2.95 to 3.4,
with glibc 2.3.2, and old-style Linux threads.
As long as you use the same tool chain to build your code as you would
use to build SDL you are fine. SDL, obviously, uses threads and works
OTOH, SDL is not thread safe. All graphics must be done in the main
“All graphics”, hmmm? Does that mean just video, or allocating
and freeing software surfaces too?
That means video and anything that may be called by the video code.
I can’t answer that question without a detailed analysis of software
surface code; I’m pretty sure (I have been in that code recently) that
if you put a wrapper around them you can call the those functions safely
in any thread. I would put a wrapper around any graphics code I used in
another thread. The problem is that some low level SDL code uses lower
level graphics code without going through the high level APIs.
I had also been hoping to
load and scale some images in a thread dedicated to clip-art.
But, like I said, SDL is not thread safe, neither are any of the SDL add
on libraries. If you want to use them in threads you have to build
wrappers for the code you want to use.
I think somebody else just said the opposite.
One of us has to be right I’ve found that being pessimistic in cases
like this save me a lot more time than being optimistic.
What does that mean to an SDL programmer? It means that you can have 10
threads reading 10 files, but only one thread can be decoding a ttf font
at a time.
This is awful. I looked over libSDL_ttf and didn’t find anything
significant. What did I miss? I saw:
a. error text might get corrupted (but no crash)
b. can’t do simultaneous TTF_Init() calls (no problem)
Regarding #a, note that libSDL_ttf does not pass '%'
in error strings. So the unsafe vararg stuff in SDL’s
error handling would not be involved.
What, you want to create a thread per font? Not a problem, read the font
file into memory and open it with TTF_OpenFontRW (use a wrapper around
it to serialize use) and you can load the fonts in parallel and you only
get serialization when you open the font. Or, just use a thread the
sequentially call TTF_OpenFont(). So long as it isn’t being called
anywhere else, there is no problem.
Now, the thing to consider is that unless you have a hyperthreading or
multicore CPU you can’t actually have more than one thread active at a
time anyway. And, having multiple threads reading from a single disk may
or may not improve disk reading performance. After all, there is only
one disk to perform the reads. So, this month you might not see the
performance improvement you expect to see. Next month you might see a
dramatic performance improvement
Raw performance is a tiny bit better. I suppose this is because one
thread can use the disk while the other uses the CPU.
Yep, and if you are trying to read many files at once you might get
better use of the disk.
Apparent performance is dramatically improved. The user can start
using the app while fonts continue to load. If the user quickly
tries to use the text tool they’ll see a progress bar and have to
wait a bit, but they can use every other part of the app without
waiting for the font scanner.
That is an obvious use of threads and should work if the scanning thread
is properly structured and take proper precautions when using SDL and
your own internal code and data.
This use implies that there will be data and code within your own
program that will have to have mutex protection.
Just and editorial comment or two if you don’t mind: Thread programming
in user space is very different from thread programming in system space.
The main difference is that in system space everything has been coded
assuming multiple threads because of interrupt processing. In use space
almost no code is written assuming multiple threads. Most libraries will
turn there toes up and die if you try to use them in a multithreaded
application without writing a serializing wrapper library.
Ouch. I expected this of init functions and functions with an API
that is inherently unsafe (like strtok).
Man, you would be surprised at the amount of local state that is kept in
FreeType solves this as a side-effect of being ROMable. There is
no static data in the library.
Which is wonderful. But, so long as you are using the SDL wrappers you
can’t be sure of what the wrappers do. BTW, there have been some recent
fixes in memory handling in the SDL_TTF library. You might want to use
the latest CVS versions of the code.
Bob PendletonOn Mon, 2005-01-24 at 12:40 -0500, Albert Cahalan wrote:
On Mon, 2005-01-24 at 09:03 -0600, Bob Pendleton wrote:
We’re going to need thread safe versions of all the libraries we use.
SDL mailing list
SDL at libsdl.org