develooper Front page | perl.perl5.porters | Postings from October 1999

Re: perlthread.pod -- First draft of thread docs

Thread Previous | Thread Next
October 28, 1999 01:29
Re: perlthread.pod -- First draft of thread docs
Message ID:
In article <>,
Dan Sugalski <> wrote:
>Comments anyone?

As someone who has not played at all with perl threads or even looked
at any other descriptions of how they work, your document seems pretty
lucid.  I am left with just a couple questions.

>will be handled properly. It's arguably a bug that the dereference is
>unconditional, rather than just done on references to blessed
>things. Don't, therefore, count on the automatic dereference working
>on references to non-blessed things.

Ouch.  Then how do you lock a scalar $ref that is a reference?
If you do lock $ref, the free dereference will trip you up.  If
you do lock \$ref, you are counting on that free dereference that
may go away.  lock bless $ref, "dummy"?

>    {
>        lock $foo;
>	cond_wait $foo unless $foo;
>    }

>    {
>        lock $foo;
>	$foo = 12;
>	cond_signal($foo);
>    }

How can the signaller get to the signal if the waiter has $foo locked?
Or does cond_wait internally release the lock during the wait?  If so,
does it restore it again after the signal?

One final question that I didn't see addressed at all.
Does local $x in one thread change what $x refers to in all threads?
If so, local is essentially unusable with threads (unless the thread
doing the local keeps the variable locked for the duration).  Seems
like there is a lot of code out there that will not ever be thread
safe due to this.

If not, we finally have a justification for calling it local instead
of save: local == thread local :)
"At most 60% of Perl is documented" -- Ilya Zakharevich

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About