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