On Tue, May 28, 2019 at 14:37:17 +0100, Richard Ipsum wrote:
> I'm unsure that it's worthwhile blocking the signals in
> 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
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?
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69