On 8/29/2021 4:41 AM, Takashi Yano wrote:
Hi Ken,
On Sat, 28 Aug 2021 16:55:52 -0400
Ken Brown wrote:
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?
I am sorry but no. I don't understand why piping C# program via
the pipe created by nt_create() has the issue. I tried to change
setup parameters in nt_create(), however, I did not succeed it to
work. I also couldn't find any mistake in nt_create() so far.
Win32 programs which use ReadFile() and WriteFile() work even
with the pipe created by nt_create() as well as overlapped I/O.
What does C# program differ from legacy win32 program at all?
I don't know.
By the way, when I introduced nt_create(), my preference would have been to
simply change create() to use the NT API, but I was afraid to do that because I
didn't want to take a chance on breaking something. That's still my preference,
if we can find a way to work around this problem with C# programs.
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
