> 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. >From RFC 178 [Atomic] operations typically lock their operands to avoid race conditions Perl source C Implementation $a = $b lock(a.mutex); lock(b.mutex); free(a.pData); a.length = b.length; a.pData = malloc(a.length); memcpy(a.pData, b.pData, a.length); unlock(a.mutex); unlock(b.mutex); > leave the locking to the coder and keep perl clean. If we don't provide this level of locking internally, then async { $a = $b } is liable to crash the interpreter. - SWM
- Re: RFC 178 (v2) Lightweight Threads Chaim Frenkel
- Re: RFC 178 (v2) Lightweight Threads Dan Sugalski
- Re: RFC 178 (v2) Lightweight Threads Chaim Frenkel
- Re: RFC 178 (v2) Lightweight Threads Dan Sugalski
- Re: RFC 178 (v2) Lightweight Threads Alan Burlison
- Re: RFC 178 (v2) Lightweight Threads Nick Ing-Simmons
- Re: RFC 178 (v2) Lightweight Threads Dan Sugalski
- Re: RFC 178 (v2) Lightweight Threads Dan Sugalski
- Re: RFC 178 (v2) Lightweight Threads Chaim Frenkel
- Re: RFC 178 (v2) Lightweight Threads Uri Guttman
- Re: RFC 178 (v2) Lightweight Threads Steven W McDougall
- Re: RFC 178 (v2) Lightweight Threads Dan Sugalski
- Re: RFC 178 (v2) Lightweight Threads Chaim Frenkel
- Re: RFC 178 (v2) Lightweight Threads Nick Ing-Simmons
- Re: RFC 178 (v2) Lightweight Threads Alan Burlison
- Re: RFC 178 (v2) Lightweight Threads Nick Ing-Simmons
- Re: RFC 178 (v2) Lightweight Threads Alan Burlison
- Re: RFC 178 (v2) Lightweight Threads Alan Burlison
- Re: RFC 178 (v2) Lightweight Threads Chaim Frenkel
- Re: RFC 178 (v2) Lightweight Threads Alan Burlison
- Re: RFC 178 (v2) Lightweight Threads Chaim Frenkel