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@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