Really slow named pipes

[Duane Clark]

This is a bit old, from May, but anyhow...

The patch to implement anonymous pipes on top of named pipes:
http://www.winehq.com/hypermail/wine-cvs/2003/05/0305.html
along with a corresponding bug fix:
http://www.winehq.com/hypermail/wine-cvs/2003/06/0123.html
causes Xilinx ISE to run really, really slow.

It has a window to which messages are sent via a pipe, and what I see 
now is that one line comes out every 2/3 of a second or so, as regular 
as a clock at least by eye. I can revert those two patches, and it goes 
back to spitting out the messages very fast. Since there are a lot of 
messages being sent, the current version slows the app down to a crawl.

It does not look like the patch itself is the problem; I am guessing 
that it is the underlying named pipe implementation that is the problem, 
which was exposed by the patch.

Also, reverting to the full CVS 5/20, just after the pipe patches, has 
the same problem. So it appears that whatever is wrong with named pipes 
(if that really is the problem) was already there on 5/20, rather than 
it being something introduced since then.

Any hints on what I could look for would be welcome.

[Uwe Bonnes]

> > > > > "Duane" == Duane Clark  writes:

Duane> This is a bit old, from May, but anyhow...  The patch to
    Duane> implement anonymous pipes on top of named pipes:
    Duane> http://www.winehq.com/hypermail/wine-cvs/2003/05/0305.html along
    Duane> with a corresponding bug fix:
    Duane> http://www.winehq.com/hypermail/wine-cvs/2003/06/0123.html causes
    Duane> Xilinx ISE to run really, really slow.

A workaround for ISE is to run the commands from pasamain.cmd_log on the
commandline. 
...

Duane> Any hints on what I could look for would be welcome.

A fix is appreaciated.

Bye

[Duane Clark]

Duane Clark wrote:
> This is a bit old, from May, but anyhow...
>
> The patch to implement anonymous pipes on top of named pipes:
> http://www.winehq.com/hypermail/wine-cvs/2003/05/0305.html
> along with a corresponding bug fix:
> http://www.winehq.com/hypermail/wine-cvs/2003/06/0123.html
> causes Xilinx ISE to run really, really slow.
>
> It has a window to which messages are sent via a pipe, and what I see 
> now is that one line comes out every 2/3 of a second or so, as regular 
> as a clock at least by eye. I can revert those two patches, and it goes 
> back to spitting out the messages very fast. Since there are a lot of 
> messages being sent, the current version slows the app down to a crawl.

A bit more info about what is happening, as best as I can tell. It looks 
like the message window is doing a PeekNamedPipe about every 2/3 of a 
second; hence the timing that I am seeing.

So the problem appears to be that in the new implementation, the write 
to the pipe is being blocked on every call, until a read has happened. 
What should be happening is that the write should only block if the pipe 
is full. Does that help someone know where to look?

[Eric Pouech]

> So the problem appears to be that in the new implementation, the write 
> to the pipe is being blocked on every call, until a read has happened. 
> What should be happening is that the write should only block if the pipe 
> is full. Does that help someone know where to look?

does this help ?

A+

[Duane Clark]

Eric Pouech wrote:
> > So the problem appears to be that in the new implementation, the write 
> > to the pipe is being blocked on every call, until a read has happened. 
> > What should be happening is that the write should only block if the pipe 
> > is full. Does that help someone know where to look?
>
> does this help ?
>
> bash: wine: command not found

Nope ;) I think there was a problem when you tried to attach that :-)

[Eric Pouech]

> Nope ;) I think there was a problem when you tried to attach that :-)

oops (took the file from the wrong dir...)

A+

[Duane Clark]

Eric Pouech wrote:
> oops (took the file from the wrong dir...)

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.

[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.

[Eric Pouech]

> 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 ?

A+

[Uwe Bonnes]

> > > > > "Eric" == Eric Pouech  writes:

>> Nope ;) I think there was a problem when you tried to attach that :-)
    Eric> oops (took the file from the wrong dir...)

Sorry for not coming back earlier. I was drouned in work...

No, the patch doesn't help :-(

Project navigator from the Xilinx Web still communicates very slow with it's
daughter processes.

[Mike Hearn]

On Sun, 2003-08-24 at 20:15, Eric Pouech wrote:
> > So the problem appears to be that in the new implementation, the write 
> > to the pipe is being blocked on every call, until a read has happened. 
> > What should be happening is that the write should only block if the pipe 
> > is full. Does that help someone know where to look?
>
> does this help ?
>
> A+

Attachment:

plain text
document
attachment (err)

bash: wine: command not found

.... at a guess, i'd say it probably doesn't help him ;)