[SDL] What are threads allowed to do?
albert at users.sf.net
Sat Jan 22 08:31:23 PST 2005
On Sat, 2005-01-22 at 11:21, Stephane Marchesin wrote:
> Albert Cahalan wrote:
> >Mere guidelines alone don't make for solid software. Am I to assume
> >that all other SDL functions are unsafe? The same for C library stuff
> >on the various supported platforms? If this is the case, then threads
> >are quite useless.
> That's the bottom line, if you don't understand threads, they do more
> harm than good.
So I "don't understand threads" if I haven't carefully examined
all of the SDL source code for thread-safety problems, along with
careful examination of documentation for Windows, BeOS, MacOS,
Linux, FreeBSD, Solaris...?
By a more common definition, I think I understand threads quite
well. I will admit to understanding them more from the viewpoint
of a kernel hacker and /bin/ps author, but that shouldn't be way
off from the user-centric viewpoint. I know spinlocks aren't so
favored in userspace, and I know there is an appalling lack of
support for the memory barriers and atomic operations needed for
> >I tried using threads, hit memory corruption problems, and...
> Well, show us a small program demonstrating memory corruption with SDL
> threads, and we'll have a chance to find the reason for this problem.
That's a tough order to fill I think.
I saw the problem in Tux Paint, which is one 15469-line file.
(yes, yes, we know -- it grew over time)
One thread was using libSDL_ttf. It scanned through about 200
font files. The thread would open a file, render some test text,
and close the file.
Meanwhile, the main app thread was mostly loading PNG images.
It would load a few hundred perhaps, along with a couple fonts
and perhaps dozens of *.wav files. The main thread has video
and sound going.
More information about the SDL