Really slow named pipes

[Duane Clark]

Duane Clark wrote:
> 
> That one came through, but unfortunately it did not fix the problem. I 
> will try to see if I can figure out a bit more about how writes to pipes 
> work.

Okay, more info about what is happening. It is not a problem of writes 
being blocked. Instead what I see is:

trace:file:CreateFileW Opening a pipe: 
L"\\\\.\\pipe\\Win32.Pipes.00000014.00000001"
trace:file:FILE_OpenPipe Returned 0x1c8
trace:file:CreateFileW returning 0x1c8
trace:file:CreatePipe Read 0x1c4 write 0x1c8
...
trace:file:WriteFile 0x1c8 0x40c13768 77 0x40c13b70 (nil)
...
trace:file:WriteFile 0x1c8 0x40c13768 75 0x40c13b70 (nil)
...
trace:file:WriteFile 0x1c8 0x40c13768 75 0x40c13b70 (nil)
...
trace:file:WriteFile 0x1c8 0x40c136ec 83 0x40c13af4 (nil)
...
trace:file:WriteFile 0x1c8 0x40c136ec 78 0x40c13af4 (nil)
...
trace:file:PeekNamedPipe  0x0000004d bytes available
...
trace:file:PeekNamedPipe  0x0000004b bytes available
...
trace:file:PeekNamedPipe  0x0000004b bytes available
...
trace:file:PeekNamedPipe  0x00000053 bytes available
...
trace:file:PeekNamedPipe  0x0000004e bytes available

Notice that the number of bytes available in each Peek corresponds 
exactly with the number that were written in each individual write. What 
should be happening of course is that the total number of bytes should 
have been reported in the first peek.