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