The only solution I am aware of is to kill the entire process. That's one
many systems are multi-process nowadays. Most JavaScript VMs have a way to
forcibly and promptly kill the VM asynchronously, but PUC Lua and LuaJIT do
not.
You can call lua_sethook from a signal handler. That is what PUC-Lua’s
SIGINT routines do.
On Sun, Jan 19, 2020, 6:18 PM Christopher Oliver <
current.input.port@xxxxxxxxx> wrote:
On Sun, 19 Jan 2020 16:38:08 -0600
demetri <demetri.spanos@xxxxxxxxx> wrote:
1) it is not recommended
2) results can be unpredictable even on a single system
3) results are system dependent
I actually understand all these. In the real code, there is specific
documentation regarding the danger inherent in this.
Assuming you agree with this, what information would help you solve your
problem?
What is on my mind is why the handler for signal 32 doesn't call the
siglongjmp() set up by pthread_cleanup_push. That memory should
be completely out of the scope of the interpreter in question. I was
hoping that there was an alternative to tracing through glibc. Honestly,
I'd expect the same (if perhaps wrong) experience across all Linux
platforms, specially when both are Intel with the same kernel and glibc
versions. That's why this makes me scratch my head.
I guess I'm needing to read the signal handler code for NPTL. This just
seems very odd.
The main application I face is shutting down a system when one or more
threads fail to terminate when requested. I'd like to determine the least
worst handling of such a less than ideal situation in general. Note that
I try to avoid this, but in the interest of completeness, a generalized
thread
package must cover this case.
I hope I'm clear. I'm not trying to be confrontational. I just want light
weight process for Lua that are as robust in the face of bad programming
as possible. Clean exits or thread systems are far from easy, and in
some cases not possible. I just want things to be as un-ugly as I can
make them when things go south.
--
Christopher Oliver <current.input.port@xxxxxxxxx>
