[squeak-dev] OSProcess and Cuis: successes and failures, cumulative changes

David T. Lewis lewis at mail.msen.com
Sat Sep 4 03:11:12 UTC 2010


On Fri, Sep 03, 2010 at 07:42:51PM -0700, Ross Boylan wrote:
> On Fri, 2010-09-03 at 19:55 -0400, David T. Lewis wrote:
> > On Fri, Sep 03, 2010 at 02:35:53PM -0700, Ross Boylan wrote:
> > > On Fri, 2010-09-03 at 16:22 -0400, David T. Lewis wrote:
> > > > > Here's the  code I put in ProtoObject
> > > > > ifNotNilDo: ifNotNilBlock
> > > > >       "RB adds for back compatibility"
> > > > >       "Evaluate the block, unless I'm == nil (q.v.)"
> > > > > 
> > > > >       ^ ifNotNilBlock valueWithPossibleArgs: {self}
> > > > 
> > > Duh.  I also need, in UndefinedObject in Cuis
> > > ifNotNilDo: aBlock
> > > 	"RB back compatibility"
> > > 	^ self
> > > 
> > > Of course the right way is to change the OSProcess code to use something
> > > more portable than ifNotNilDo:.
> > 
> > 
> > Hi Ross,
> > 
> > I have updated both OSProcess and CommandShell on SqueakSource to address
> > all of the #ifNotNilDo: issues for Cuis, as well as the #fork issues that
> > you previously addressed. I think that I've captured all of your fixes.
> > Thank you *very* much for this.
> > 
> > I did not actually load into Cuis to check, but a lot of the issues
> > were in the unit tests so I expect they will run properly now (knock
> > wood).
> > 
> > And I have to give a grudging nod of appreciation to Juan for forcing
> > me to address the #ifNotNilDo: concerns. At first I was annoyed that I
> > had to rewrite a lot of code, but I have to admit that by the time I
> > was done I had cleaned out a lot of ugly cruft from OSProcess, so
> > I guess once again Juan has got it right :)
> > 
> > Dave
> The latest changeset files in cleanly to a new Cuis2.7 image (in
> particular, I did not add any hacks for ifNotNilDo:).  All 190 tests
> passed the first 2 or 3 times I ran the tests, but, after running the
> 2.6 tests below, I got various failures in 2.7.
> UnixProcessUnixFileLockingTestCase>>testCooperatingProcesses02 failed
> once, and then
> UnixProcessUnixFileLockingTestCase>>testCooperatingProcesses04 the next
> time.
> 
> The 2.6 and 2.7 tests were in different directories.  In the initial 2.7
> tests only that image was up, while in all later cases both were up. 
> The 2.7 image seems to do somewhat better than 2.6.  When I start from a
> fresh Cuis2.6 image, I get non-deterministic failures.  The first test
> suite run hung up, from memory at UnixProcessTestCase>>testCatAFile.
> The last two runs failed in
> UnixProcessWin32FileLockingTestCase>>testCooperatingProcesses04.
> 
> I shut down the 2.7 image and tried running just the 2.6.  There was one
> failure, in
> UnixProcessUnixFileLockingTestCase>>testCooperatingProcesses04.
> 
> Juan, do you have any ideas what changes between 2.6 and 2.7 might be
> relevant, or what might be causing these failure patterns?

It is very possible that the problems are either in my unit tests, or
in OSProcess/CommandShell. Many of the tests involve cooperating OS
processes and are timing dependent. It would be good to understand what
has changed between 2.6 and 2.7, but my working assumption would be
that any changes in Cuis might make bugs in OSProcess/CommandShell
more probable, but are not necessarily the root cause. The file locking
tests are an example of tests that rely on cooperating OS processes,
and that could fail due to timing issues of one sort of another.

I note that CommandShellTestCase in particular is a real torture
test for process scheduling, and Pharo images have tended to choke
on these tests. Again, I don't assume that Pharo is the root cause,
just that the behavior seems to be different.

Dave




More information about the Squeak-dev mailing list