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 ZakharevichThread Previous | Thread Next