On Fri, 4 May 2001, Alan Burlison wrote:
> Chris Stith wrote:
>
> > So, in short, you are saying to allow threading on platforms where
> > it can be done in C, and forego threading support elsewhere? This
> > is certainly one path to take, but it is not what I had understood
> > people to want.
>
> I think an implicit assumption is that the platform has pthreads - I
> sincerely hope you aren't suggesting that perl does it's own threads
> implementation.
Having pthreads != being threadsafe at the C level. There are many
other factors.
> > Short of either kicking everyone who writes a libc in the butt until
> > they write them to be threadsafe or rewriting the libcs for every
> > platform for which we compile and distributing them with perl (I think
> > the former is more likely, by however small a margin ;-) we can't
> > really count on being threadsafe at the C library level, ever. I
> > guess a third astronimically unlikely scenario would be to port Perl
> > to the level of an embedded app with no need of the system libc. All
> > of these solutions are abyssal. The question is how to do threads
> > in the circumstances we actually have at hand.
>
> You miss the point - the libc and sundry other library authors are most
> times constrained by the various historic interfaces that they are obligated
> to be compliant with in order to satisfy existing standards. Quite often it
> is impossible to make interfaces thread safe without changing the interface,
> thus breaking standards compliance. When people still expect to be able to
> run 20 year old code on a brand new platform, you have a real problem.
> Welcome to the grown up world of computing.
True. It's not that i don't understand backwards compatibility. It's
just that I'm spoiled by my Open Source software. I can see how this
would be more difficult at Sun or HP than at RedHat, where the whole
OS and all the tools on it ship freshly compiled and with source. In
a completely Open Source world, we wouldn't have to worry, as (almost)
everything would be rebuilt around the new version of the library
anyway. As things are, though, it is not an ideal situation to update
to newer libraries.
> > If we mark some things as thread safe and others as not, then we
> > can let perl get out of the way when something is thread safe, and
> > we can have it step forward to create all those nasty and brutish
> > thread-local storage locations and serialization queues which slow
> > execution and use extra memory only when they are needed.
>
> If you have followed the entire thread you will se that this is not a fix.
> You cannot guarentee to be able to fix a binary library by this route. The
> library may have internal state that you can't get at, and it may make
> internal calls in a non NT-safe way, for example. There is usually a way
> around these problems, but there is no generic way. Such workarounds tend
> to be fragile, and suceptible to being broken by purely internal changes to
> the library. It's not impossible, just very hard. What is pretty much
> impossible is to come up with a generic way to resolve all such issues.
If you serialize the calls, then anything that happens inside the
binary library doesn't happen at the same time between threads.
Period. If you wait until one call to localtime() has returned
before making another, for example, then the two calls cannot
possibly interfere with one another. This doesn't make localtime()
thread-safe, and indeed it somewhat defeats the purpose of using
threads for the duration of the serialization, but it does make
sure that localtime() doesn't need to be reentrant to be called
from your program, because it won't be called in a way that makes
that necessary. The only library calls, then, that would be very
difficult to surround this way would be things such as iterators
or memoizing functions. Even recursion within a library function
can be handled via serialization.
Granted, memoizing functions and iterators in libraries could
be important exceptions for some people, but how common is it to
find this sort of functionality in a binary library?
I still believe the main question about serialization and thread-local
storage is whether or not it's worth the effort, not whether or not
it would be possible to do.
Chris
--
Product shown enlarged to make you think you're getting more.
