Front page | perl.perl5.porters |
Postings from October 1999
In article <3.0.6.32.19991022103610.00c711c0@tuatha.sidhe.org>,
Dan Sugalski <dan@sidhe.org> 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