Alan Burlison <[EMAIL PROTECTED]> writes: >Nick Ing-Simmons wrote: > >> The tricky bit i.e. the _design_ - is to separate the op-ness from the >> var-ness. I assume that there is something akin to hv_fetch_ent() which >> takes a flag to say - by the way this is going to be stored ... > >I'm not entirely clear on what you mean here - is it something like >this, where $a is shared and $b is unshared? > > $a = $a + $b; > >because there is a potential race condition between the initial fetch of >say $a and the assignment to it? >My response to this is simple - tough. That is mine too - I was trying to deduce why you thought op tree had to change. I can make a weak case for $a += $b; Expanding to a->vtable[STORE](DONE => 1) = a->vtable[FETCH](LVALUE => 1) + b->vtable[FETCH](LVALUE => 0); but that can still break easily if b turns out to be tied to something that also dorks with a. -- Nick Ing-Simmons
- Re: RFC 178 (v2) Lightweight ... Nick Ing-Simmons
- Re: RFC 178 (v2) Lightweight ... Alan Burlison
- Re: RFC 178 (v2) Lightweight ... Alan Burlison
- Re: RFC 178 (v2) Lightweight ... Chaim Frenkel
- Re: RFC 178 (v2) Lightweight ... Alan Burlison
- Re: RFC 178 (v2) Lightweight ... Chaim Frenkel
- Re: RFC 178 (v2) Lightweight ... Alan Burlison
- Re: RFC 178 (v2) Lightweight ... Steven W McDougall
- Re: RFC 178 (v2) Lightweight ... Steven W McDougall
- Re: RFC 178 (v2) Lightweight ... Chaim Frenkel
- Re: RFC 178 (v2) Lightweight ... Nick Ing-Simmons
- Re: RFC 178 (v2) Lightweight ... Chaim Frenkel
- Re: RFC 178 (v2) Lightweight ... Alan Burlison
- Re: RFC 178 (v2) Lightweight ... Steven W McDougall
- Re: RFC 178 (v2) Lightweight ... Bryan C . Warnock
- Re: RFC 178 (v2) Lightweight ... Steven W McDougall
- Re: RFC 178 (v2) Lightweight ... Nick Ing-Simmons
- Re: RFC 178 (v2) Lightweight ... raptor
- Re: RFC 178 (v2) Lightweight ... Chaim Frenkel
- Re: RFC 178 (v2) Lightweight Threads Glenn King
- Re: RFC 178 (v2) Lightweight Threads Jarkko Hietaniemi