On Fri, 4 May 2001, Benjamin Sugars wrote:
> On Fri, 4 May 2001, Chris Stith wrote:
>
> > Obviously, you are lost in the fact that only half of the paragraph
> > is being referenced in your response. ;-) The original mentions pros
> > and cons of updating the libraries on both types of OSes.
>
> Sorry if I wasn't clear. My point is that we cannot blithely
> s/localtime/localtime_r/g on perl/*.c because the perl source needs to
> remain buildable on both the old and the new platforms. The fact that it's
> easier to upgrade some systems to reentrant interfaces does not change
> this.
This means it would be YAIF for Jarkko. (yet another ifdef forest.)
The recurring theme here seems to be 'is it worth the effort?'
I have to admit, it may not be. en again, I'm not one of the ones
who thinks Perl 5 withut threads is a deadly sin. ;-)
> > > I do not think this is true. The first call can return a pointer to
> > > static data. Subsequent threads can clobber this data.
> >
> > This is why 'serilization' and 'thread-local storage' go hand in hand,
> > and have rarely been mentioned more than five lines apart througout
> > the thread. It is for exactly this situation that thread-local
> > storage is so important. If a call returns a pointer, then it should
> > be part of the serialization process to dereference the pointer,
> > grab the value, and put it someplace private to the current thread.
>
> OK, that's not what I mean by serialization. Your scheme is something
> over and above what I think of as serialization. (The pedants on the list
> will probably be quick to point what the correct terminology is.)
I'm not sure what the proper terminology is for doing both at
the same time. I'm not sure there is proper terminology for it,
but I'm sure that if there is we'll soon find out fro someone
on the list. ;-)
> Now that I understand your scheme, I do agree that it could be made to
> work but I'm still not convinced it's worth the effort.
I will agree that it's a lot of effort. So is the end-user toying
with a program endlessly to figure out what will work in his threaded
program.
Whether or not the effort is worthwhile in the core is largely
up to the pumpking. Even if I had a perfect implementation of
what i'm talking about fall into my lap from Heaven, whether or
not it would be worthwhile to ship with the core would still be
in question because it's such a drastic step.
> > Of course, if I do the following in a single-threaded program,
> > the second call clobbers the data from the first anyway:
> >
> > my $time;
> > $time = localtime;
> > $time = localtime;
> >
> > Does this mean that localtime() is not single-thread safe?
>
> It means you have a bug :-)
Precisely! Just as you would have a bug if you did the equivalent
thing in a multi-threaded program. By storing all the values
local to the thread which are not safe to share (or perhaps even
grabbing values through returned pointers and putting them in
thread-shared memory, as long as you store the value and not the
pointer), you get to avoid clobbering the value in somewhat the
same way. Yes, it takes more processor time. Yes, it takes more
memory. However, example 'a' below takes more memory and processor
time than example 'b':
a)
my $time1;
my $time2;
$time1 = localtime;
$time2 = localtime;
b)
my $time;
$time = localtime;
$time = localtime;
By using the resources available, example 'a' does something
which preserves the value of a prior call to the same function.
This is not so much different from making sure that threaded
code grabs the values and stores them.
I know that localtime(3) in C returns a pointer to a struct tm.
This doesn't bother me. This isn't C. Perl should be able to
return thread-proper data when running threaded programs.
Chris
--
The purpose of a language is not to help you learn the
language, but to help you learn other things by using the
language. --Larry Wall, The Culture of Perl, August 1997
