[cdt-dev] Re: PipeInputStream/PipeOutputStream and ProcessClosure

["Alain Magloire" <alain@xxxxxxx>]

Bonjour,

  The good thing about mailing lists is the capability to retrieve old comments/feedbacks 8-).
Chris S. made a _very_ interesting analysis of the behaviour of the CommandLauncher, we
never had a chance to dig in closer.  dinglis(Dave) commited a bunch of changes
removing the pipes, so heads up to you Chris and thanks for the feedback, as usual
extremmely usefull.

=====================================================
    * From: Chris Songer <songer@xxxxxxxxxxxxx>
    * Date: Fri, 23 Apr 2004 17:54:00 -0700
    * Delivered-to: cdt-dev@xxxxxxxxxxx

We are using Sun's 1.4.2 JRE and on the Win32 platform we are seeing some 
ugly behavior between CommandLauncher and ProcessClosure caused, 
apparently, by a bad implementation of PipeInputStream and PipeOutputStream.

To finally isolate the problem to a particular area, we upped the buffer 
size in ProcessClosure to 16k and instrumented the routine so that it 
logged how much it read from it's stream and when it read it. Recall that 
ProcessClosure turns around and writes that data to the PipeOutputStream. 
We also upped the buffer size to 16k in CommandLauncher and had it log how 
much it read from the PipeInputStream and when it read it.

The pattern was unmistakable. ProcessClosure would read big blocks 
instantly. It would turn around and write those big blocks. CommandLauncher 
would get 1k blocks from the Pipe and it would get those blocks 1 second 
apart. The pipe streams were the trouble.

This was totally unacceptable for us. The behavior effectively hung the IDE 
in certain cases.

The fix was to write new streams for piping. I'm happy to send them, but 
suspect it's not generally interesting since it seems JRE and platform 
related. Feel free to drop me email if this is interesting to you, I'm 
happy to send along the new pipestream classes and the patch to 
commandlauncher.

Thanks!
-Chris
songer@xxxxxxxxxxxxx