<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 31, 2015 at 5:05 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
On Wed, Dec 30, 2015 at 05:15:40AM +0000, Eliot Miranda wrote:<br>
<span class="">><br>
> > On Dec 29, 2015, at 2:38 AM, Mariano Martinez Peck <<a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a>> wrote:<br>
> ><br>
> > Hi guys,<br>
> ><br>
> > 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.<br>
> ><br>
> > 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?<br>
><br>
</span>> 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.<br>
><br>
> 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.<br>
><br>
> (& running on bare metal as in SqueakNOS requires enable/disable interrupts to allow interrupt delivery at appropriate times)<br>
><br>
<br>
Yes, it is important that a unix signal be delivered to a thread that<br>
can handle it, and yes that means using pthread signal handling<br>
mechanisms.<br>
<br>
In OSPP, this is done by #maskForThisThreadAndResend: which is called<br>
from the single handler #handleSignal: in the case of a signal being<br>
delivered to some thread other than the main interpreter thread.<br>
<br>
This ensures that #signalSemaphoreWithIndex: (which actually does the<br>
signal send to the Smalltalk Semaphore) is only ever called from the<br>
main interpreter thread as required.<br>
<br>
The theory here is that for any signal that we want to redirect to a<br>
Semaphore in the image, eventually all threads other than the main<br>
interpreter thread get masked off, and that signal will be delivered<br>
directly to the correct thread without further need to call<br>
#maskForThisThreadAndResend: to re-send the signal.<br>
<br>
Note that there is no way to know all of the threads that may be<br>
running, because some random plugin might choose to start up some<br>
new pthreads without your knowledge. That's the reason for the<br>
approach I took of just checking to see if the current thread is<br>
the main interpreter thread, and if it is not then mask off that<br>
thread and arrange for the signal to be re-delivered.<br></blockquote><div><br></div><div>Hi Dave,</div><div><br></div><div>Thanks for the answer. Let me ask you something else.... <span style="font-size:12.8px">primitiveForwardSignalToSemaph</span><span style="font-size:12.8px">ore 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 :)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Could you confirm this? (the fact that I could use #primitiveForwardSignalToSemaphore outside OSProcess project? </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So...ideally, I think we could split </span><span style="font-size:12.8px">UnixOSProcessPlugin plugin in more general one and the OSProcess mostly - related. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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 </span><span style="font-size:12.8px">UnixOSProcessPlugin primitives for the tool I am developing. </span></div><div> </div></div>Thanks in advance!<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div></div>