public inbox for cygwin-cvs@sourceware.org help / color / mirror / Atom feed
From: Corinna Vinschen <corinna@sourceware.org> To: cygwin-cvs@sourceware.org Subject: [newlib-cygwin] Cygwin: pipes: drop "tiny pipe" handling Date: Tue, 14 Sep 2021 15:07:09 +0000 (GMT) [thread overview] Message-ID: <20210914150709.B9B3B385781A@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=27b24069d16623ac21e858d998bbaf008c3f0924 commit 27b24069d16623ac21e858d998bbaf008c3f0924 Author: Corinna Vinschen <corinna@vinschen.de> Date: Tue Sep 7 12:56:48 2021 +0200 Cygwin: pipes: drop "tiny pipe" handling Given we return 1 already if WriteQuotaAvailable is > 0, the condition for tiny pipes is never true. Fix the comments. Signed-off-by: Corinna Vinschen <corinna@vinschen.de> Diff: --- winsup/cygwin/select.cc | 22 +++++++--------------- 1 file changed, 7 insertions(+), 15 deletions(-) diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc index ac2fd227e..5e338e43f 100644 --- a/winsup/cygwin/select.cc +++ b/winsup/cygwin/select.cc @@ -608,10 +608,12 @@ pipe_data_available (int fd, fhandler_base *fh, HANDLE h, bool writing) } if (writing) { - /* If there is anything available in the pipe buffer then signal - that. This means that a pipe could still block since you could - be trying to write more to the pipe than is available in the - buffer but that is the hazard of select(). */ + /* WriteQuotaAvailable is decremented by the number of bytes requested + by a blocking reader on the other side of the pipe. Cygwin readers + are serialized and never request a number of bytes equivalent to the + full buffer size. So WriteQuotaAvailable is 0 only if either the + read buffer on the other side is really full, or if we have non-Cygwin + readers. */ if (fpli.WriteQuotaAvailable > 0) { paranoid_printf ("fd %d, %s, write: size %u, avail %u", fd, @@ -619,17 +621,7 @@ pipe_data_available (int fd, fhandler_base *fh, HANDLE h, bool writing) fpli.WriteQuotaAvailable); return 1; } - /* If we somehow inherit a tiny pipe (size < PIPE_BUF), then consider - the pipe writable only if it is completely empty, to minimize the - probability that a subsequent write will block. */ - if (fpli.OutboundQuota < PIPE_BUF - && fpli.WriteQuotaAvailable == fpli.OutboundQuota) - { - select_printf ("fd, %s, write tiny pipe: size %u, avail %u", - fd, fh->get_name (), fpli.OutboundQuota, - fpli.WriteQuotaAvailable); - return 1; - } + /* TODO: Buffer really full or non-Cygwin reader? */ } else if (fpli.ReadDataAvailable) {
reply other threads:[~2021-09-14 15:07 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210914150709.B9B3B385781A@sourceware.org \ --to=corinna@sourceware.org \ --cc=cygwin-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).