[Vm-dev] Custom signal handler?

[David T. Lewis]

On Wed, Dec 30, 2015 at 05:15:40AM +0000, Eliot Miranda wrote:
> 
> > On Dec 29, 2015, at 2:38 AM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
> > 
> > Hi guys,
> > 
> > I am checking UnixOSProcessPlugin >> primitiveForwardSignalToSemaphore and it seems it needs to do quite some work in order to place a signal handler for things like SIGCHLD in order to get a Smalltalk semaphore signaled upon receiving SIGCHLD or whatever signal.
> > 
> > So...I wonder...is there something today (nowadays) in latest VM that would allow me to set such a handler without such kind of primitive?
> 
> No.  You could use the FFI and a callback to call signal but since signal delivery is asynchronous it would cause havoc when the signal invoked the callback at an arbitrary time.
> 
>  If signal handlers can be installed that deliver to a specific thread (ptherad_signal?) and you set it to deliver to some dedicated thread that is idling then the threaded FFI would manage the timing.
> 
> (& running on bare metal as in SqueakNOS requires enable/disable interrupts to allow interrupt delivery at appropriate times)
> 

Yes, it is important that a unix signal be delivered to a thread that
can handle it, and yes that means using pthread signal handling
mechanisms.

In OSPP, this is done by #maskForThisThreadAndResend: which is called
from the single handler #handleSignal: in the case of a signal being
delivered to some thread other than the main interpreter thread.

This ensures that #signalSemaphoreWithIndex: (which actually does the
signal send to the Smalltalk Semaphore) is only ever called from the
main interpreter thread as required.

The theory here is that for any signal that we want to redirect to a
Semaphore in the image, eventually all threads other than the main
interpreter thread get masked off, and that signal will be delivered
directly to the correct thread without further need to call
#maskForThisThreadAndResend: to re-send the signal.

Note that there is no way to know all of the threads that may be
running, because some random plugin might choose to start up some
new pthreads without your knowledge. That's the reason for the
approach I took of just checking to see if the current thread is
the main interpreter thread, and if it is not then mask off that
thread and arrange for the signal to be re-delivered.

Dave