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.