Really slow named pipes

Eric Pouech pouech-eric at
Sat Sep 13 13:52:29 CDT 2003

> 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.
I made some further tests and basically FIONREAD semantics differ on 
pipe and socketpair. On pipe, it will return the sum of all non read 
data. On socketpair, it will only return the size of non read data from 
the first pending write call. Of course, it creates some delays in 
PeekNamedPipe. recv behaves the same.

So, as a solution, we could replace the socketpair call in the server 
with a pipe one (this would break on platforms where pipe create a 
unidirectional pipe - or we could even detect it and fall back to 
socketpair with a know degradation).

Any other idea ?


Eric Pouech

More information about the wine-devel mailing list