[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: hook question
- From: Glenn Maynard <glenn@...>
- Date: Wed, 11 Oct 2006 22:41:20 -0400
On Wed, Oct 11, 2006 at 09:22:29PM -0500, Rici Lake wrote:
> Thinking about that for a few more minutes, I realized that one could
> eschew signals altogether in favour of a single alarm thread which woke
> up every so often and sethook'd any lua_State's registered with it. In
> that case, the thread safety of sethook would be an issue.
>
> If it's not threadsafe as written (it looks ok to me, but as David
> Jones says, it's hard to say for sure), then it cannot be fixed by
> simply adding lua_lock and lua_unlock to it; that would make it
> unusable in a signal handler, and moreover would not solve the problem
> that was posed originally, because the entire VM runs inside the lock
> and therefore the sethook wouldn't acquire the lock until the VM
> released it (for example, by calling a CFunction), which might never
> happen.
This is why I suggested separate signal and thread versions of
lua_sethook.
As for the VM releasing the lock: that's the purpose of luai_threadyield,
right?
--
Glenn Maynard
- References:
- Re: hook question, Mike Pall
- Re: hook question, David Jones
- Re: hook question, Mike Pall
- Re: hook question, David Jones
- Re: hook question, Mike Pall
- Re: hook question, Glenn Maynard
- Re: hook question, Roberto Ierusalimschy
- Re: hook question, Glenn Maynard
- Re: hook question, Rici Lake
- Re: hook question, Rici Lake