On 8/28/2021 11:43 AM, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 13:58:08 +0200
Corinna Vinschen wrote:
On Aug 28 18:41, Takashi Yano via Cygwin wrote:
On Sat, 28 Aug 2021 10:43:27 +0200
Corinna Vinschen wrote:
On Aug 28 02:21, Takashi Yano via Cygwin wrote:
On Fri, 27 Aug 2021 12:00:50 -0400
Ken Brown wrote:
Two years ago I thought I needed nt_create to avoid problems when calling
set_pipe_non_blocking.  Are you saying that's not an issue?  Is
set_pipe_non_blocking unnecessary?  Is that the point of your modification to
raw_read?

Yes. Instead of making windows read function itself non-blocking,
it is possible to check if the pipe can be read before read using
PeekNamedPipe(). If the pipe cannot be read right now, EAGAIN is
returned.

The problem is this:

   if (PeekNamedPipe())
     ReadFile(blocking);

is not atomic.  I. e., if PeekNamedPipe succeeds, nothing keeps another
thread from draining the pipe between the PeekNamedPipe and the ReadFile
call.  And as soon as ReadFile runs, it hangs indefinitely and we can't
stop it via a signal.

Hmm, you are right. Mutex guard seems to be necessary like pty code
if we go this way.

Is a blocking ReadFile actually faster than a non-blocking read?  Or
does it mainly depend on BYTE vs. MESSAGE mode?

Actually, I don't think so. Perhaps it is not essential problem of
overlapped I/O but something is wrong with current pipe code.

What if the pipe is created non-blocking and stays non-blocking all the
time and uses BYTE mode all the time?  Just as sockets, it would always
only emulate blocking mode.  Wouldn't that drop code size a lot and fix
most problems?

If 'non-blocking' means overlapped I/O, only the problem will be:
https://cygwin.com/pipermail/cygwin/2021-March/247987.html

Sorry if that wasn't clear, but I was not talking about overlapped I/O,
which we should get rid off, but of real non-blocking mode, which
Windows pipes are fortunately capable of.

Do you mean, PIPE_NOWAIT flag? If this flags is specified in
the read pipe, non-cygwin apps cannot read the pipe correctly.

While waiting for Corinna's response to this, I have one more question. Do you understand why nt_create() failed and you had to revert to create()? Was it an access problem because nt_create requested FILE_WRITE_ATTRIBUTES? Or did I make some careless mistake in writing nt_create?

Ken

--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

Reply via email to