[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Time constraint in Lua pattern functions
- From: "Soni L." <fakedme@...>
- Date: Wed, 30 Mar 2016 09:49:21 -0300
On 30/03/16 08:11 AM, Viacheslav Usov wrote:
On Mon, Mar 14, 2016 at 9:54 PM, Sean Conner <sean@conman.org
<mailto:sean@conman.org>> wrote:
> If the code was purely Lua, then time_restricted_pcall() would be
easily written. However, if any calls to C are made, then it gets
complicated and requires system specific code to handle.
That is hardly different from a native application being blocked on a
kernel call, and we all know that being able to break user-mode
execution is still very useful for debugging. By the same token, it
would be very useful to be able to break just the Lua VM when it is
not running any native code.
We have debug hooks, which almost do the right thing with the "break
on N instructions" feature, but they need to be set in advance, and
choosing the N is not straightforward because it implies a performance
vs responsiveness trade-off. It would be nice to have something like
lua_break() that can be called on a Lua environment (which may be
running some Lua code in another native thread), which would
essentially call a user-supplied function before the next VM
instruction gets executed, or at some other convenient VM execution
milestone not very distant in future, in the original native thread.
Speaking of blocking native code, I do not think a fully generic
portable solution is possible. Library writers, however, know (in
principle) when their native code can possibly take a while (or block
on a kernel call), and could then make that interruptible and/or
cancellable. Then all it takes is a way to communicate to Lua that a
given native function is interruptible/cancellable, and some
convention to request interruption/cancellation.
Cheers,
V.
Allowing native code to trigger debug hooks and stuff would be nice.
--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.