Really slow named pipes
pouech-eric at wanadoo.fr
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 ?
More information about the wine-devel