Re: hook question

[Rici Lake <lua@...>]

On 16-Oct-06, at 8:19 AM, Roberto Ierusalimschy wrote:

> The problem is the non-atomicity of pointer accesses. There is a small
> risk that, while luaD_callhook is reading L->hook, lua_sethook changes
> it, so that luaD_callhook reads an invalid pointer.
>
> I cannot see any simple way to correct this, without imposing some
> restrictions on lua_sethook.

Good point.

The simplest solution would be to use something like lua_enablehook() 
in the signal handler, and insist that the hook function be set 
previously. That may not solve every use case, but it certainly solves 
the problem of activating a hook when a timer signal goes off.

That should work in the multiprocessor model as well, provided that

1) there is some datatype which can be atomically written

and

2) it's possible to figure out what that datatype is.

I'd be surprised if (1) were false for any existing architecture, but I 
have no idea how to solve (2).