Chris Stith wrote:
> > You need to consider libraries other than the system ones, for example those
> > wrapped by XSUB modules.
>
> Then that leaves XS modules and stuff like libpng/zlib/libkrb5, etc.
> But if it's XS, then we don't have to worry about not having the
> source. The source is on CPAN. ;-) So what we need to worry about
> are proprietary libraries that are non-system and are not available
> as source. Although I feel that in a perfect world this wouldn't
> happen ;-), I'm certain that there are a great many libraries out
> there which fit these specs.
Yes, indeed there are.
> In any case, it may be that the module writer should be held
> responsible to either declare the underlying library thread-safe
> and document his module accordingly, or to document his module
> to say that it is not thread-safe. I realize this means that not
> all code will ever be able to be thread-safe, but that's where
> we are now.
That's on onerous responsibility - don't forget, a lot of kind people have
contributed lots of time and code to wrap external libraries for which they
are not responsible, and we don't want to make the task any more burdensome
for them. Lots of these people aren't qualified to make statements about
the thread safety of the underlying library - especially if they don't have
source.
> I think the goal is to make as much thread-safe as possible,
> while having some way to keep hapless Perl programmers from
> using thread-unsafe calls in threaded code. I'm just trying
> to figure out a way to meet these goals. I thank you for
> shooting holes in specifics, but so far I don't think you've
> made a strong case that we have to have all thread-safe code
> throughout the world before Perl can use threads safely with
> certain caveats.
I'd actually prefer that the interpreter dies if it is asked to load
non-threadsafe code in a threaded context. Any threadsafe code should have
to explicitly and programatically declare itself to be thread-safe. I'll
take safety over speed any time.
Alan Burlison
