On Tue, Oct 10, 2006 at 02:07:51PM +0200, Mike Pall wrote:
This assumes that updates to each of hookmask and hook will take
place atomically. There's no guarantee of that. On some
architectures an update of hook may consist of two writes (to two
halves of a 64-bit quantity say) and a re-ordered write to hookmask
may appear in between them.
Please. If updates to a pointer sized quantity (32 bit on 32 bit
systems, 64 bit on 64 bit systems) are non-atomic, fire the CPU
designer team. AFAIK none of the 64 bit multi-core machines on
the market do this.
This seems like a rather narrow and dismissive attitude for a system
that goes to such lengths to be portable. Portability means working
on architectures with a different set of warts than x86.
"lua_sethook can be called from a thread or signal handler" notion
should be qualified. It's safe if you're simply enabling a count
hook of 1, so long as
1: the hook was previously disabled, and
2: if you're calling from a thread (not a signal handler),
either a: writes to pointer-sized fields must be atomic
or b: writes must be strictly ordered. Either (a) or (b)
should make it safe, so long as (1) is satisfied.
For any other case, the user needs to examine the code to know
the caveats.
David, can you see any holes in the above? If writes are strictly
ordered, then a nonatomic write to the function pointer will never
be used until the mask is written. A nonatomic write to any other
field appears harmless--not sure about hookmask, which is a byte
and might clobber simultaneous writes to allowhook. If writes are
not strictly ordered, but writes are atomic, then it might cause
a spurious no-op hook call, which is harmless.
