On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote:
> > Le 10/10/2014 17:52, David T. Lewis a ?crit :
> >>> 2014-10-10 14:09 GMT+02:00 David T. Lewis <le...@mail.msen.com>:
> >>>
> >>>>
> >>>> Right. But please do test it in your applications to be sure, I really
> >>>> only
> >>>> did simple testing and I am sure there may still chances for problems
> >>>> in
> >>>> this area.
> >>>>
> >>>
> >>> Hi Dave,
> >>>
> >>> Would it has a chance of slowing down things a lot?
> >>>
> >>> There is apparently something going very very slow compared to
> >>> OSProcess
> >>> 4.5.11 when used from GitFileTree. So slow that I killed the image
> >>> building
> >>> script before it was over. Reverting GitFileTree to 4.5.11 solved it.
> >>>
> >>
> >> I don't this so, but I am not certain. The update for PipeableOSProcess
> >> affects only the methods in PipeableOSProcess class>>command: and
> >> closely
> >> related methods. If GitFileTree is using that idiom, then it is
> >> certainly
> >> possible that I have introduced a bug that does not show up in my unit
> >> tests.
> >
> > Typical code in GitFileTree is this:
> >
> > [
> > c := PipeableOSProcess command: ''.
> > output := c output.
> > ...
> > ] ensure: [c closePipes]
> >
> > Maybe it's triggering something.
> >
> > Thierry
> >
>
> Hmmm... I wonder if the #closePipes is causing a problem now. I don't know
> if I ever tested to see if sending closePipes works after the pipes are
> already closed, and my recent change closes the pipes after #output is
> evaluated. I'll check it when I get home.
>
I tried this in both Squeak trunk and Pharo 3.0:
(1 to: 100) collect: [:e | | c output |
[c := PipeableOSProcess command: 'ls -lt'.
output := c output.
] ensure: [c closePipes].
output ].
I get the expected results, and no open file handles left over.
The #closePipes is no longer needed, so this can now be simplified as follows,
which also leaves no open file handles:
(1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') output].
I am not sure what the issue is when used with GitFileTree, but it does not
look like the change to PipeableOSProcess class>> command: is directly involved.
But ... I'm probably missing something.
If you are fairly sure the that problem is related to the the PipeableOSProcess
change, then the only other thing I can think of right now is that there may
be some other places in GitFileTree where PipeableOSProcess is being used in
a different way, and maybe I caused a problem there due the the change in the
#command: methods. But this a a complete guess, I really do not know.
Dave
