On Fri, 4 May 2001, Benjamin Sugars wrote:
> On Fri, 4 May 2001, Chris Stith wrote:
>
> > 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.
>
> You've lost me. We want perl to build on both the old and the new.
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.
> > 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.
>
> 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.
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? Or does
it just mean that in order to keep a value around you have to put
it somewhere you know won't get overwritten?
Chris
--
Disclaimer: Actual product may not resemble picture in ad in any way.
