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.
> > 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.)
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.
> 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 :-)
Cheers,
-Ben
--
signer: can't create ~/.sig: Resource temporarily unavailable
