[Vm-dev] Custom signal handler?

Mariano Martinez Peck marianopeck at gmail.com
Thu Dec 31 20:38:02 UTC 2015


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?

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.

Thanks in advance!


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151231/dba1884b/attachment.htm


More information about the Vm-dev mailing list