Re: [coLinux-devel] Re: [PATCH] bjh i/o improvement, causes heavy CPU usage on Win2k

[Henry N. <Henry.Ne@Arcor.de>]

Jonathan,

thanks for comment and background.

Debug-log from W2K
http://www.henrynestler.com/colinux/pipe-bjh/20050512/nt57.zip

Same action on XP
http://www.henrynestler.com/colinux/pipe-bjh/20050512/xp57.zip

Please grep for fltk. The "loop ..." give information about actual state 
mode. Please ignore some other difference. Log are also created from 
difference hardware. The logfiles are for hard developers only and not 
use on stable branch!

The used source for debuging (for locking varaiable names in log)
http://www.henrynestler.com/colinux/pipe-bjh/20050512/daemon-debug.c


Ballard, Jonathan wrote:
> I intended it to read in byte stream mode.  That way it can burst I/O
> operations, which allows it to read several messages in one I/O call. Less
> I/O operations means less CPU overhead.  The state machine is written
> specifically for byte stream mode.
> 
> After the a message is read, it tests if it can burst the next operation to
> read many messages. It subtracts the amount of data allocated for the first
> message and uses that value for the next ReadFileEx.  Then it scans the read
> buffer and splits it up into individual messages without another I/O
> operation.

The pipe is created/open, for message stream mode.

Under W2K can't set it to byte stream mode after open.
W2K still ignore all other parameters in SetNamedPipeHandleState. Only 
PIPE_READMODE_MESSAGE is allowed (if open with PIPE_TYPE_MESSAGE).

If you sayed, reading functions are byte stream oriented, we can open 
pipe with PIPE_TYPE_BYTE and PIPE_READMODE_BYTE. Perhaps?
http://msdn.microsoft.com/library/en-us/ipc/base/createnamedpipe.asp

I will check this.

> PeekNamePipe is not a good function as it seems.  It is better to queue an
> asynchronous I/O with ReadFileEx and await the return event, and use the
> returned information to build the next action.  This is why it queues a read
> for 20 bytes, the message header. Then PeekNamePipe may be used to only test
> for the total number of bytes that can be read, which could consist of
> several messages.

Other option is, read again without waiting the rest of bytes.
Yes, ReadFileEx returned true and counters in iodata say we have more bytes.

This I will try this weekend. :-)

>>+        long lpMode = PIPE_READMODE_MESSAGE;
>>+        if (!SetNamedPipeHandleState(handle, &lpMode, 0, 0))
>>+            co_debug_lvl(pipe,10,"error %x SetNamedPipeHandleState",
> 
> 
> This doesn't fix the bug, it just avoids it. The problem is why would it
> succeed to set it to byte stream mode on XP and not on Win2K?

Yes, it is not a fix for W2K. But it use the pipe in same mode under XP, 
W2K and other Win-versions in future. ;-)

W2K can't change to byte mode after open pipe. Have tested. W2K igore 
the parameter PIPE_READMODE_BYTE in SetNamedPipeHandleState. No error, 
no GetLastError. Still ignored, and the overkill: 
GetNamedPipeHandleState sayed, it is in byte stream mode. But isn't Peek 
and ReadEx give differ count of bytes.

-- 
Henry Nestler