It appears that, due to the semantics of SelfLoader, SDL::Contants is
not thread-safe (when using 5.8.x's ithreads).  Specifically, it's the
way SelfLoader works that is the problem.

As far as I can tell, since SelfLoader reads after the __DATA__ tag, and
doing so is actually reading from a file handle, and the file handle's
state is shared between threads, then when one thread tries to cache
SDL::Contants data at the first invocation, it eats up all the content
(or some of it) (this is a guess at the problem, from looking at the
SelfLoader debug output).  When another thread invokes an autoloaded
function in SDL::Constants via SelfLoader, the filehandle is no longer
positioned at a location in __DATA__ that the function to be defined can
be found.

I found a work around, but it causes segfaults at global destruction
time at script exit.  You can get SelfLoader to cache everything before
you create threads by referencing one of the functions it will autoload,
something like the following block:

   { my $x = SDL_ANYFORMAT; }


A better solution, at the cost of some startup time (faster startup time
is AFAICT the only reason to use SelfLoader), is to just not use
SelfLoader for SDL::Constants.  Removing, from SDL/Constants.pm, the
"use SelfLoader;", the SelfLoader debug line and __DATA__ lines does
that.

Some magic could be done by detecting if the script is going to use
threads by checking the value of $threads::threads and then use
different modules.

I suppose this could be considered a SelfLoader bug.

-- 
Andy Bakun <[EMAIL PROTECTED]>

Reply via email to