>>>>> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:
UG> i don't see how you can do atomic ops easily. assuming interpreter
UG> threads as the model, an interpreter could run in the middle of another
UG> and corrupt it. most perl ops do too much work for any easy way to make
UG> them atomic without explicit locks/mutexes. leave the locking to the
UG> coder and keep perl clean. in fact the whole concept of transactions in
UG> perl makes me queasy. leave that to the RDBMS and their ilk.
If this is true, then give up on threads.
Perl will have to do atomic operations, if for no other reason than to
keep from core dumping and maintaining sane states.
If going from an int to a bigint is not atomic, woe to anyone using
threads.
If it is atomic, then the ++ has to be atomic, since the actual operation
isn't complete until it finishes.
Think ++$a (before int, after ++ value is bigint)
Some series of points (I can't remember what they are called in C)
where operations are consider to have completed will have to be
defined, between these points operations will have to be atomic.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
