On Fri, 4 May 2001, Benjamin Sugars wrote:
> On Fri, 4 May 2001, Chris Stith wrote:
>
> > My suggestion is to let libraries that are threadsafe (system
> > libraries as well as Perl moduels would be nice) be used as such
> > so the advantages of that can be realized, while at the same time
> > defaulting to serialized calls for libraries which are not, so
> > your threaded programs which need to call nonreentrant functions
> > can do so with some level of safety.
>
> I still don't buy it. Consider a non-thread-safe getpwnam(), and
> serialized access from two threads:
>
> Thread | Operation
> 1 | struct passwd *ent = getpwnam("valid");
> 2 | struct passwd *ent = getpwnam("invalid");
> 1 | printf("home: %s\n", ent->pw_dir); /* boom; ent is NULL */
>
> So to make the Perl code C<$id = getpwnam()> safe, I think perl would not
> only have to serialize calls, but copy the data from the static pointer
> into thread-local storage.
Indeed. We are talking about trying to make things more threadsafe,
aren't we?
> Should perl be given this overhead on all platforms just for the benefit
> of those with non-thread-safe libcs? Probably not; it should probably
> call a reentrant interface if available. But the reentrant interfaces are
> all different. Hence the foam frothing from Jarkko's mouth.
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.
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.
There's no way perl can know if a user is going to write a program
which calls something which is not thread-safe. With XS, syscall(),
Inline, and platform-specific thigns such as Win32::API, there's a
good chance a user will call something that's not safe from within
a threaded program. That's not the question.
The question is, do we want to minimize the damage someone can do
by calling something which is not thread-safe or just allow perl
to puke on what happens when the user calls something wrongly?
Perhaps we should just not allow threading at all, then we don't
have to worry.
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.
I doubt Perl runs very many places, if any, where _everything_ is
thread-safe. If we just forego threading, we're slowing down
performance that way. If we let the user call anything as if it
was thread-safe, then we risk doing all sorts of rude things from
Perl which perl isn't supposed to allow, so we've given up
reliability. If we assign serilization queues and thread-local
storage to everything, then we gain reliability and some performance
over not allowing threads at all, although we do have the overhead
you mention. If we allow for thread-local storage and serialization
of calls only when necessary, then we might hit a happy medium.
I may be entirely wrong. I don't think so, but you may be able to
prove me 100% wrong. I think what I'm talking about would work. I
haven't studied very deeply how to go about implementing such a
compromise just yet, and I have a feeling it would be very difficult
to implement properly. I do think, though, that if we really want
threading available on any decent number of platforms without
throwing the burnt corpse of reliability upon the altar, we must
do something other than allowing random unsafe calls to be called
from htreaded programs.
Chris
--
Get real! This is a discussion group, not a helpdesk. You post
something, we discuss its implications. If the discussion happens to
answer a question you've asked, that's incidental. -- nobull, clp.misc
