[SDL] What are threads allowed to do?

[Albert Cahalan]

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
lockless code.

> >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.