needed one OSProcessPlugin for darwin/osx

David T. Lewis lewis at mail.msen.com
Sun Mar 5 17:48:10 UTC 2006


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 at smalltalkconsulting.com> 1-800-477-2659
> > Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> > ======================================================================== 
> > ===
> > 



More information about the Squeak-dev mailing list