>>>>> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Well, there'll be safe access to individual variables when perl needs to
DS> access them, but that's about it.
DS> Some things we can guarantee to be atomic. The auto increment/decrement
DS> operators can be reasonably guaranteed atomic, for example. But I don't
DS> think we should go further than "instantaneous access to shared data will
DS> see consistent internal data structures".
what if i do $i++ and overflow into the float (or bigint) domain? that
is enough work that you would need to have a lock around the ++. so then
all ++ would have implied locks and their baggage. i say no atomic ops
in perl.
CF> This is going to be tricky. A list of atomic guarentees by perl will be
CF> needed.
CF> $a[++$b];
CF> pop(@a);
CF> push(@a, @b);
CF> Will these?
CF> And given that users will be doing the locking. What do you see for
CF> handling deadlock detection and recovery/retry.
i don't see how you can do atomic ops easily. assuming interpreter
threads as the model, an interpreter could run in the middle of another
and corrupt it. most perl ops do too much work for any easy way to make
them atomic without explicit locks/mutexes. leave the locking to the
coder and keep perl clean. in fact the whole concept of transactions in
perl makes me queasy. leave that to the RDBMS and their ilk.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
