.. although this is not sufficient.  After leaving the test script running for some 3.5m signals, I get another lockup.

Finding all the interruptible syscalls that need to be protected is surely going to be tedious and error-prone .. but a whole-hog solution of turning signals into event-loop events, while simpler to code, is going to require changes in every existing extension that (mis-)uses signals.


This particular mole stuck its head up with the following stack.  Now testing with EINTR handling to FileInputProc/FileOutputProc, though I'm not really convinced this is sensible:


#0  0x00007f7d482b3afd in __lll_lock_wait () from
#1  0x00007f7d482ada0d in pthread_mutex_lock () from
#2  0x00007f7d48aa8a6b in Tcl_MutexLock (mutexPtr=0x1bd6060) at
#3  0x00007f7d4891d4ae in Tcl_AsyncMark (async=0x1dfbc78) at
#4  <signal handler called>
#5  0x00007f7d48aa8a89 in Tcl_MutexUnlock (mutexPtr=0x1bd6060) at
#6  0x00007f7d4891d5c6 in Tcl_AsyncInvoke (interp=0x1bce2f8, code=0) at
#7  0x00007f7d489232c1 in NRCommand (data=0x1c87060, interp=0x1bce2f8, result=0) at
#8  0x00007f7d48923129 in TclNRRunCallbacks (interp=0x1bce2f8, result=0, rootPtr=0x1c86fd8) at
#9  0x00007f7d48925a9e in TclEvalObjEx (interp=0x1bce2f8, objPtr=0x1bd6060, flags=131072, invoker=0x0, word=0) at
#10 0x00007f7d48925a34 in Tcl_EvalObjEx (interp=0x1bce2f8, objPtr=0x0, flags=131072) at
#11 0x00007f7d48a355cc in TclChannelEventScriptInvoker (clientData=0x1d3bfd8, mask=2) at
#12 0x00007f7d48a34e03 in Tcl_NotifyChannel (channel=0x1d26db8, mask=2) at
#13 0x00007f7d48a35003 in ChannelTimerProc (clientData=0x1d26db8) at
#14 0x00007f7d48a827aa in TimerHandlerEventProc (evPtr=0x1ddaf18, flags=-3) at
#15 0x00007f7d48a58ecf in Tcl_ServiceEvent (flags=-3) at
#16 0x00007f7d48a591d7 in Tcl_DoOneEvent (flags=-3) at
#17 0x00007f7d489ee656 in Tcl_VwaitObjCmd (clientData=0x0, interp=0x1bce2f8, objc=2, objv=0x1bd1970) at