Hi John,
I managed to overcome my squeamishness about pthreads long enough to write pthread-aware signal forwarding for OSPP. This is at:
http://www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins-OSProcessPlugin-dtl.3.mcz
The approach I took is: - OSPP plugin initialization remembers pthread ID of the interpreter. - After calling signal forwarding primitive, OSPP sets signal handler to forward SIGFOO to Squeak semaphore. - On receipt of signal, the handler in OSPP checks to see if it is executing in the context of the interpreter pthread. if in interpreter thread: signal the Squeak semaphore. otherwise: set sigmask to prevent future delivery of SIGFOO to this pthread. resend the signal to the interpreter pthread.
This seems to all work fine on my Linux system (meaning that it does not break anything), and I did some tests to make sure the signal re-sending mechanism works. So the idea would be that on OS X, Squeak would be able to handle signals such as SIGCHLD by having any non-interpreter threads that receive the signal just resend it to the correct interpreter pthread, and also mask the signal so it does not end up going to the wrong pthread next time.
If you try this, you would want to change #canForwardExternalSignals back to true.
I would still like to know if #testRunCommand passes on your current configuration, that's an important data point.
Thanks,
Dave
On Sat, Mar 04, 2006 at 06:18:10PM -0500, David T. Lewis wrote:
Thanks John,
A key question is whether forking a simple process works:
"(UnixProcessTestCase selector: #testRunCommand) run"
Forking a running Squeak image is a rather tricky business. By contrast, a fork-and-exec to run an external program is simple, and has a good chance of working as long as we steer clear of the pthreads signal handling for the time being.
Let me know if #testRunCommand passes.
Dave
On Sat, Mar 04, 2006 at 02:22:40PM -0800, John M McIntosh wrote:
Ok, I'm running a few tests this am, mind perhaps there are no OS-X OSProcessPlugin users out there? however thank you for taking the time to look into this.
First I went in and mangled MacOSProcessAccessor and MacProcess to remove the overrides for access to unix superclass logic then I prim failed the forksqueak prim call, and made the suggested change to UnixOSProcessAccessor>>canForwardExternalSignals
Testing
UnixProcessAccessorTestCase>testIsExecutableForUserInGroup accessor isExecutable: '/tmp/delete.me' forUser: 99999 inGroup: accessor primGetGid fails, but I'll note: -r-xr-x--- 1 johnmci wheel 0 Mar 4 13:47 /tmp/delete.me
testIsReadableForUserInGroup didn't look likely related to above testIsWriteableForUserInGroup didn't look likely related to above
testChDir for this accessor primGetCurrentWorkingDirectory returns /private/tmp on the mac
UnixProcessFileLockingtestCase wants to fork a headless squeak.... They all fail then...
UnixProcessFileLockTestcase They all RUN (GREEN)
UnixProcessTestCase 5 run, 13 error because they all attempt to fork a squeak vm.
Likely I should look at the ancient code for headless squeak, if there is any visible demand?
On 4-Mar-06, at 7:28 AM, David T. Lewis wrote:
On Thu, Mar 02, 2006 at 12:33:02AM -0800, John M McIntosh wrote:
ok, after some clues from David I built a mostly broken unix vm, however it was enough to build a OSProcessPlugin as a side effect.
In testing I see that calling primitiveForkSqueakWithoutSigHandler crashes things, I'll suspect forking the carbon vm is a no no.
Hi John,
If you have a chance, could you please try something for me? Change the method UnixOSProcessAccessor>>canForwardExternalSignals to answer false, then save your image and restart.
--
=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===