[Vm-dev] Custom signal handler?

[David T. Lewis]

On Thu, Dec 31, 2015 at 05:38:02PM -0300, Mariano Martinez Peck wrote:
>  
> On Thu, Dec 31, 2015 at 5:05 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> > 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.
> >
> 
> Hi Dave,
> 
> Thanks for the answer. Let me ask you something else....
> primitiveForwardSignalToSemaphore looks quite generate to me and quite
> decoupled from OSProcess itself, correct?   I have seen quite some stuff
> in UnixOSProcessPlugin which are way more general than that OSProcess job,
> and that would benefit other users, like me :)
> 
> Could you confirm this?  (the fact that I could use
> #primitiveForwardSignalToSemaphore outside OSProcess project?

Yes that is exactly right. It would be quite reasonable to put 
#primitiveForwardSignalToSemaphore into another plugin, and I'll be
happy to help you with that if you see an advantage to it.

> 
> So...ideally, I think we could split UnixOSProcessPlugin plugin in more
> general one and the OSProcess mostly - related.
> 
> In the meanwhile...let me ask... Dave, are you planning to continue giving
> support to the plugin for future developments of the VM itself (Spur now,
> then Spur 64, etc etc) ??   If true, then I may use (at least temporary)
> some of the UnixOSProcessPlugin primitives for the tool I am developing.
>

Yes, I will continue supporting it. The plugin is not tightly coupled with
the VM, and it already works on Spur. I expect no issues with 64-bit Spur.

The only big deficiency in OSPP is that I never finished the Windows
implementation. I really should try to do that one of these years :-)

Cheers!

Dave