On Fri, 4 May 2001, Alan Burlison wrote:
> Chris Stith wrote:
>
> > Memoization and iteration are fairly high-level details. IMHO,
> > they shouldn't be in system libraries. They may be there, but
> > it wouldn't take long to figure out which library functions do
> > this if you were to start trying to use them in a threaded
> > program. The world is not perfect. As long as there are issues
> > with libraries you use, there will be issues with your code
> > as well. All we can do, short of replacing all the libraries,
> > is to minimize the damage.
>
> 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.
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.
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.
Chris
--
Programming is a tool. A tool is neither good nor evil. It is
the user who determines how it is used and to what ends.
