On Tue, May 28, 2019 at 08:30:49PM +0100, Daniel Silverstone wrote:
On Tue, May 28, 2019 at 14:37:17 +0100, Richard Ipsum wrote:
> > I'm unsure that it's worthwhile blocking the signals in this fashion,
> > though I suppose it saves either losing signals or having to queue them
> > in luxio rather than in the kernel.
> I've been thinking about this and it seems absolutely necessary.
> If you don't block them while you're handling then there's nothing to
> stop another signal coming in and clobbering everything while you're
> still trying to handle the first one. You can queue them yourself
> but nothing stops a signal being delivered while you're performing
> operations on your queue, seems safer to let the OS do the queueing.
Fair, I accept your reasoning.
> I've been implementing a possible solution to avoid the limit of one
> VM but I have to say that I don't like it, it seems a lot more fragile
> to me and so I'm wondering whether there is really any compelling
> reason that Luxio would worry about supporting handlers set by
> multiple VMs? If not then maybe we just document this limitation?
As I (think) I said before - I'm okay with the limitation as long as it is
clearly documented, and ideally protected against (i.e. if you attempt to
register a signal handler from a Lua state which isn't the one cached
in the global context, then you get an error return from the function call)
Does that sound okay to you?
Yeah, I'll make those changes then.