From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?
Date: Thu, 2 Sep 2021 20:54:11 +0200 [thread overview]
Message-ID: <YTEd031zU7k+26Uw@calimero.vinschen.de> (raw)
In-Reply-To: <20210902171549.72910cf8e01c822233bfc56a@nifty.ne.jp>
Hi Takashi,
On Sep 2 17:15, Takashi Yano wrote:
> On Wed, 1 Sep 2021 10:46:24 +0200
> Corinna Vinschen wrote:
> > On Sep 1 17:23, Takashi Yano wrote:
> > > One idea is:
> > >
> > > Count read handle and write handle opned using NtQueryObject().
> > > If the numbers of opened handle are equal each other, only
> > > the write side (pair of write handle and query_hdl) is alive.
> > > In this case, write() returns error.
> > > If read side is alive, number of read handles is greater than
> > > number of write handles.
> >
> > Interesting idea. But where do you do the count? The event object
> > will not get signalled, so WFMO will not return when performing a
> > blocking write.
>
> I imagined something like attached patch.
>
> Unfortunately, the attached patch seems to have bug that
> occasionally causes the following error while building
> cygwin1.dll.
>
> <command-line>: error: "GCC_VERSION" redefined [-Werror]
> <command-line>: note: this is the location of the previous definition
> cc1plus: all warnings being treated as errors
> make[1]: *** [Makefile:1942: fhandler_proc.o] Error 1
> diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
> index 1f0f28077..38390848f 100644
> --- a/winsup/cygwin/fhandler.h
> +++ b/winsup/cygwin/fhandler.h
> @@ -1172,6 +1172,7 @@ class fhandler_pipe: public fhandler_base
> {
> private:
> HANDLE query_hdl;
> + HANDLE reader_evt;
> pid_t popen_pid;
> size_t max_atomic_write;
> void set_pipe_non_blocking (bool nonblocking);
> @@ -1181,6 +1182,7 @@ public:
> bool ispipe() const { return true; }
>
> HANDLE get_query_handle () const { return query_hdl; }
> + bool reader_closed ();
>
> void set_popen_pid (pid_t pid) {popen_pid = pid;}
> pid_t get_popen_pid () const {return popen_pid;}
> diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
> index 2d9e87bb3..4773d04da 100644
> --- a/winsup/cygwin/fhandler_pipe.cc
> +++ b/winsup/cygwin/fhandler_pipe.cc
> @@ -51,6 +51,8 @@ fhandler_pipe::set_pipe_non_blocking (bool nonblocking)
> fpi.ReadMode = FILE_PIPE_BYTE_STREAM_MODE;
> fpi.CompletionMode = nonblocking ? FILE_PIPE_COMPLETE_OPERATION
> : FILE_PIPE_QUEUE_OPERATION;
> + if (get_device () == FH_PIPEW)
> + fpi.CompletionMode = FILE_PIPE_COMPLETE_OPERATION;
Ok, so the write side is always non-blocking...
> status = NtSetInformationFile (get_handle (), &io, &fpi, sizeof fpi,
> FilePipeInformation);
> if (!NT_SUCCESS (status))
> @@ -308,6 +310,22 @@ fhandler_pipe::raw_read (void *ptr, size_t& len)
> }
> else if (status == STATUS_THREAD_CANCELED)
> pthread::static_cancel_self ();
> +
> + if ((ssize_t)len > 0)
> + SetEvent (reader_evt);
> +}
...and every successful read sets the event object to signalled.
Sounds good.
> + }
> +
> if (len <= max_atomic_write)
> chunk = len;
> else if (is_nonblocking ())
> @@ -400,10 +425,24 @@ fhandler_pipe::raw_write (const void *ptr, size_t len)
> /* NtWriteFile returns success with # of bytes written == 0
> if writing on a non-blocking pipe fails because the pipe
> buffer doesn't have sufficient space. */
> - if (nbytes_now == 0 && nbytes == 0)
> + if (nbytes_now == 0 && nbytes == 0 && is_nonblocking ())
> set_errno (EAGAIN);
> - ptr = ((char *) ptr) + chunk;
> + ptr = ((char *) ptr) + nbytes_now;
> nbytes += nbytes_now;
> + if (reader_closed () && nbytes == 0)
> + {
> + set_errno(EPIPE);
> + raise(SIGPIPE);
> + }
> + if (!is_nonblocking () && nbytes < len)
> + {
> + if (nbytes_now == 0)
> + {
> + cygwait (reader_evt);
> + ResetEvent (reader_evt);
But what if a read calls SetEvent between cygwait and ResetEvent?
This looks like a potential deadlock issue, no?
> + }
> }
> else if (STATUS_PIPE_IS_CLOSED (status))
> {
> @@ -430,9 +469,14 @@ fhandler_pipe::raw_write (const void *ptr, size_t len)
> void
> fhandler_pipe::fixup_after_fork (HANDLE parent)
> {
> + if (close_on_exec() && query_hdl)
> + CloseHandle (query_hdl);
Why do you close the handle here? It gets already created with
inheritence settings according to the O_CLOEXEC flag.
> if (query_hdl)
This is broken. If you close query_hdl above, it's still != NULL
and fork_fixup will be called.
> fork_fixup (parent, query_hdl, "query_hdl");
> fhandler_base::fixup_after_fork (parent);
> + if (!close_on_exec ())
> + DuplicateHandle (parent, reader_evt, GetCurrentProcess (), &reader_evt,
> + 0, 1, DUPLICATE_SAME_ACCESS);
Uhm... this is fixup_after_fork. I'm a bit puzzled. You create the
event object with inheritence set to TRUE unconditionally. So the
forked process will have this handle anyway. If you duplicate the
handle here, you'll have a handle leak. What about creating and
duplicating with inheritance == !(flags & O_CLOEXEC) and just call
fork_fixup?
> @@ -463,7 +510,11 @@ fhandler_pipe::close ()
> {
> if (query_hdl)
> NtClose (query_hdl);
> - return fhandler_base::close ();
> + int ret = fhandler_base::close ();
> + if (get_device () == FH_PIPER)
> + SetEvent (reader_evt);
> + CloseHandle (reader_evt);
> + return ret;
> }
What do you do if the reader process gets killed or crashes? I fear
this solution has the same problem as a solution using a self-implemented
counter.
Corinna
next prev parent reply other threads:[~2021-09-02 18:54 UTC|newest]
Thread overview: 250+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <41A583E1-C8E7-42AB-9F24-EEC33A41EC60@house.org>
[not found] ` <20210825201845.07b6400b79dc5558a7761efe@nifty.ne.jp>
[not found] ` <f8106fe7-a2b8-d106-3061-4d888124f4b0@cornell.edu>
[not found] ` <20210826062934.54f2f2216021c095bb7ba13b@nifty.ne.jp>
[not found] ` <d0a8c57d-1ed1-6b4f-c6e7-cbe0e2ec8a1c@cornell.edu>
[not found] ` <3b560051-ab27-f392-ca4b-d1fd9b5733b0@cornell.edu>
[not found] ` <20210827202440.47706fc2fc07c5e9a1bc0047@nifty.ne.jp>
[not found] ` <4f2cb5f3-ce9c-c617-f65f-841a5eca096e@cornell.edu>
[not found] ` <20210828022111.91ef5b4ff24f6da9fadb489e@nifty.ne.jp>
[not found] ` <YSn3L0W1M527utK0@calimero.vinschen.de>
[not found] ` <20210828184102.f2206a8a9e5fe5cf24bf5e45@nifty.ne.jp>
[not found] ` <YSok0PoCQn2TPPrn@calimero.vinschen.de>
[not found] ` <20210829004346.c2f80469abc3a07fd4b2918d@nifty.ne.jp>
[not found] ` <e8caa02f-be85-33bc-3f09-347c1cdb0923@cornell.edu>
[not found] ` <20210829174124.0c1ae6c16a3e8da1f490abc7@nifty.ne.jp>
[not found] ` <6e9bb35e-6f4f-cf78-e515-549da487b5ef@cornell.edu>
2021-08-30 7:57 ` Corinna Vinschen
[not found] ` <20210829180729.48b4e877f773cb3980c5766d@nifty.ne.jp>
[not found] ` <789f056a-f164-d71d-1dc9-230f5a41846d@cornell.edu>
2021-08-30 8:27 ` Corinna Vinschen
2021-08-30 13:00 ` Corinna Vinschen
2021-08-30 13:20 ` Corinna Vinschen
2021-08-30 13:41 ` Ken Brown
2021-08-30 14:12 ` Corinna Vinschen
2021-08-30 14:52 ` Ken Brown
2021-08-30 15:15 ` Corinna Vinschen
[not found] ` <20210830043756.8aa0ada77db0bfbbe3889f62@nifty.ne.jp>
[not found] ` <47e5dd74-b940-f305-fd5a-c6c9d8f41305@cornell.edu>
2021-08-30 8:48 ` Corinna Vinschen
[not found] ` <c62d18df-ab7a-7233-62ee-29a8eced5353@cornell.edu>
[not found] ` <20210830091314.f9a2cb71794d0f68cdb5eba7@nifty.ne.jp>
[not found] ` <20210830092259.52f7d54fc3fa340738373af4@nifty.ne.jp>
[not found] ` <d217ef03-7858-5e22-0aa6-f0507eedd9da@cornell.edu>
[not found] ` <20210830170204.fa91eaf110f310f13b67abc3@nifty.ne.jp>
2021-08-30 10:20 ` Corinna Vinschen
2021-08-30 10:38 ` Corinna Vinschen
2021-08-30 12:04 ` Takashi Yano
2021-08-30 12:55 ` Corinna Vinschen
2021-08-30 13:31 ` Corinna Vinschen
2021-08-31 8:50 ` Takashi Yano
2021-08-30 13:51 ` Ken Brown
2021-08-30 15:00 ` Ken Brown
2021-08-30 15:19 ` Corinna Vinschen
2021-08-30 15:43 ` Ken Brown
2021-08-31 9:43 ` Corinna Vinschen
2021-08-31 8:52 ` Takashi Yano
2021-08-31 9:04 ` Corinna Vinschen
2021-08-31 11:05 ` Takashi Yano
2021-08-31 15:20 ` Corinna Vinschen
2021-09-01 2:39 ` Takashi Yano
2021-09-01 8:03 ` Corinna Vinschen
2021-09-01 8:13 ` Corinna Vinschen
2021-08-30 13:36 ` Ken Brown
2021-08-30 14:05 ` Corinna Vinschen
2021-08-30 15:53 ` Corinna Vinschen
2021-08-30 17:00 ` Corinna Vinschen
2021-08-30 17:11 ` Corinna Vinschen
2021-08-30 18:59 ` Ken Brown
2021-08-30 19:12 ` Ken Brown
2021-08-30 20:21 ` Corinna Vinschen
2021-08-30 20:14 ` Corinna Vinschen
2021-08-30 20:47 ` Ken Brown
2021-08-31 8:55 ` Takashi Yano
2021-08-31 9:08 ` Corinna Vinschen
2021-08-31 9:25 ` Takashi Yano
2021-08-31 10:05 ` Corinna Vinschen
2021-08-31 10:18 ` Corinna Vinschen
2021-08-31 11:45 ` Takashi Yano
2021-08-31 12:31 ` Takashi Yano
2021-08-31 15:08 ` Corinna Vinschen
2021-08-31 12:33 ` Ken Brown
2021-08-31 15:18 ` Corinna Vinschen
2021-08-31 15:27 ` Corinna Vinschen
2021-08-31 15:50 ` Corinna Vinschen
2021-08-31 16:19 ` Ken Brown
2021-08-31 16:38 ` Ken Brown
2021-08-31 17:30 ` Corinna Vinschen
2021-08-31 18:54 ` Ken Brown
2021-08-31 19:51 ` Corinna Vinschen
2021-08-31 23:02 ` Takashi Yano
2021-09-01 0:16 ` Takashi Yano
2021-09-01 8:07 ` Corinna Vinschen
2021-09-01 8:23 ` Takashi Yano
2021-09-01 8:46 ` Corinna Vinschen
2021-09-01 12:56 ` Ken Brown
2021-09-01 13:52 ` Corinna Vinschen
2021-09-01 23:02 ` Ken Brown
2021-09-02 8:17 ` Corinna Vinschen
2021-09-02 13:01 ` Ken Brown
2021-09-02 19:00 ` Corinna Vinschen
2021-09-02 19:34 ` Ken Brown
2021-09-02 19:35 ` Corinna Vinschen
2021-09-02 20:19 ` Ken Brown
2021-09-03 9:12 ` Corinna Vinschen
2021-09-03 19:00 ` Ken Brown
2021-09-03 19:53 ` Ken Brown
2021-09-03 19:54 ` Corinna Vinschen
2021-09-03 20:05 ` Ken Brown
2021-09-03 10:00 ` Takashi Yano
2021-09-03 10:13 ` Takashi Yano
2021-09-03 11:31 ` Corinna Vinschen
2021-09-03 11:41 ` Corinna Vinschen
2021-09-03 12:13 ` Ken Brown
2021-09-03 15:00 ` Corinna Vinschen
2021-09-03 15:14 ` Ken Brown
2021-09-03 15:17 ` Corinna Vinschen
2021-09-03 12:22 ` Takashi Yano
2021-09-03 13:27 ` Ken Brown
2021-09-03 15:37 ` Corinna Vinschen
2021-09-04 12:02 ` Takashi Yano
2021-09-04 12:37 ` Takashi Yano
2021-09-04 14:04 ` Ken Brown
2021-09-04 23:15 ` Takashi Yano
2021-09-05 13:40 ` Takashi Yano
2021-09-05 13:50 ` Takashi Yano
2021-09-05 18:47 ` Ken Brown
2021-09-05 19:42 ` Takashi Yano
2021-09-05 20:09 ` Takashi Yano
2021-09-05 20:27 ` Ken Brown
2021-09-06 8:13 ` Corinna Vinschen
2021-09-06 11:16 ` Takashi Yano
2021-09-06 12:49 ` Corinna Vinschen
2021-09-06 13:16 ` Takashi Yano
2021-09-06 16:08 ` Corinna Vinschen
2021-09-06 23:39 ` Takashi Yano
2021-09-07 9:14 ` Corinna Vinschen
2021-09-07 11:03 ` Takashi Yano
2021-09-07 16:14 ` Ken Brown
2021-09-07 18:26 ` Corinna Vinschen
2021-09-03 10:38 ` Takashi Yano
2021-09-08 11:32 ` Takashi Yano
2021-09-08 11:55 ` Corinna Vinschen
2021-09-08 12:33 ` Takashi Yano
2021-09-08 17:43 ` Ken Brown
2021-09-08 18:28 ` Corinna Vinschen
2021-09-02 8:15 ` Takashi Yano
2021-09-02 18:54 ` Corinna Vinschen [this message]
2021-09-07 3:26 ` Takashi Yano
2021-09-07 10:50 ` Takashi Yano
2021-09-08 0:07 ` Takashi Yano
2021-09-08 4:11 ` Takashi Yano
2021-09-08 9:01 ` Takashi Yano
2021-09-08 9:01 ` Corinna Vinschen
2021-09-08 9:26 ` Corinna Vinschen
2021-09-08 9:45 ` Takashi Yano
2021-09-08 10:04 ` Corinna Vinschen
2021-09-08 10:45 ` Takashi Yano
2021-09-08 10:51 ` Corinna Vinschen
2021-09-09 3:21 ` Takashi Yano
2021-09-09 9:37 ` Corinna Vinschen
2021-09-09 10:55 ` Takashi Yano
2021-09-09 11:41 ` Corinna Vinschen
2021-09-08 9:37 ` Takashi Yano
2021-09-09 3:41 ` Takashi Yano
2021-09-09 8:05 ` Takashi Yano
2021-09-09 12:19 ` Takashi Yano
2021-09-09 12:42 ` Takashi Yano
2021-09-09 21:53 ` Takashi Yano
2021-09-10 3:41 ` Takashi Yano
2021-09-10 10:57 ` Ken Brown
2021-09-10 15:17 ` Ken Brown
2021-09-10 15:26 ` Corinna Vinschen
2021-09-10 22:57 ` Takashi Yano
2021-09-11 2:17 ` Ken Brown
2021-09-11 2:35 ` Takashi Yano
2021-09-11 13:12 ` Ken Brown
2021-09-12 6:23 ` Takashi Yano
2021-09-12 14:39 ` Ken Brown
2021-09-13 9:11 ` Corinna Vinschen
2021-09-13 12:30 ` Ken Brown
2021-09-12 8:48 ` Takashi Yano
2021-09-12 11:04 ` Takashi Yano
2021-09-12 15:10 ` Ken Brown
2021-09-12 21:46 ` Ken Brown
2021-09-12 23:54 ` Takashi Yano
2021-09-13 2:19 ` Ken Brown
2021-09-13 8:40 ` Takashi Yano
2021-09-13 12:51 ` Ken Brown
2021-09-13 17:05 ` Ken Brown
2021-09-13 9:42 ` Corinna Vinschen
2021-09-13 13:03 ` Ken Brown
2021-09-13 18:39 ` Takashi Yano
2021-09-12 23:41 ` Takashi Yano
2021-09-13 17:42 ` Ken Brown
2021-09-13 18:54 ` Takashi Yano
2021-09-13 18:32 ` Corinna Vinschen
2021-09-13 19:37 ` Takashi Yano
2021-09-13 20:15 ` Corinna Vinschen
2021-09-14 8:07 ` Takashi Yano
2021-09-14 8:47 ` Corinna Vinschen
2021-09-14 12:38 ` Ken Brown
2021-09-14 14:15 ` Corinna Vinschen
2021-09-14 8:08 ` Takashi Yano
2021-09-14 9:03 ` Corinna Vinschen
2021-09-14 9:56 ` Takashi Yano
2021-09-14 10:19 ` Takashi Yano
2021-09-14 11:03 ` Corinna Vinschen
2021-09-14 12:05 ` Takashi Yano
2021-09-14 14:17 ` Corinna Vinschen
2021-09-14 22:14 ` Ken Brown
2021-09-15 0:21 ` Takashi Yano
2021-09-15 0:44 ` Takashi Yano
2021-09-15 0:59 ` Takashi Yano
2021-09-15 9:57 ` Corinna Vinschen
2021-09-15 10:48 ` Takashi Yano
2021-09-15 10:58 ` Takashi Yano
2021-09-15 11:34 ` Corinna Vinschen
2021-09-15 11:40 ` Corinna Vinschen
2021-09-15 11:13 ` Corinna Vinschen
2021-09-15 11:41 ` Ken Brown
2021-09-15 11:49 ` Corinna Vinschen
2021-09-15 11:54 ` Takashi Yano
2021-09-15 12:20 ` Corinna Vinschen
2021-09-15 13:04 ` Takashi Yano
2021-09-15 13:42 ` Corinna Vinschen
2021-09-15 16:22 ` Ken Brown
2021-09-15 17:09 ` Ken Brown
2021-09-16 0:22 ` Takashi Yano
2021-09-16 2:28 ` Ken Brown
2021-09-16 9:09 ` Takashi Yano
2021-09-16 13:02 ` Takashi Yano
2021-09-16 13:25 ` Corinna Vinschen
2021-09-16 14:27 ` Takashi Yano
2021-09-16 15:01 ` Corinna Vinschen
2021-09-16 15:46 ` Ken Brown
2021-09-16 16:02 ` Ken Brown
2021-09-16 19:42 ` Takashi Yano
2021-09-16 20:28 ` Ken Brown
2021-09-16 19:48 ` Ken Brown
2021-09-16 20:01 ` Takashi Yano
2021-09-17 2:25 ` Ken Brown
2021-09-17 8:31 ` Takashi Yano
2021-09-17 11:16 ` Ken Brown
2021-09-17 16:23 ` Takashi Yano
2021-09-17 17:08 ` Ken Brown
2021-09-17 17:39 ` Jon Turney
2021-09-17 17:43 ` Takashi Yano
2021-09-17 19:53 ` Ken Brown
2021-09-18 1:30 ` Takashi Yano
2021-09-18 2:07 ` Ken Brown
2021-09-18 2:10 ` Ken Brown
2021-09-18 8:03 ` Takashi Yano
2021-09-18 11:12 ` Ken Brown
2021-09-18 11:35 ` Takashi Yano
2021-09-18 14:11 ` Jon Turney
2021-09-18 13:44 ` Ken Brown
2021-09-19 1:31 ` Takashi Yano
2021-09-19 14:35 ` Ken Brown
2021-09-20 9:29 ` Takashi Yano
2021-09-16 0:13 ` Takashi Yano
2021-09-16 2:26 ` Ken Brown
2021-09-13 9:07 ` Corinna Vinschen
2021-09-20 12:52 ` Takashi Yano
2021-09-20 19:14 ` Ken Brown
2021-09-20 21:09 ` Ken Brown
2021-09-20 21:21 ` Ken Brown
2021-09-20 21:27 ` Takashi Yano
2021-09-20 21:39 ` Ken Brown
2021-09-20 22:16 ` Takashi Yano
2021-09-20 22:46 ` Ken Brown
2021-09-20 22:50 ` Ken Brown
2021-09-20 23:22 ` Takashi Yano
2021-09-21 8:30 ` Takashi Yano
2021-09-21 9:26 ` Mark Geisert
2021-09-21 10:10 ` Takashi Yano
2021-09-21 21:10 ` Mark Geisert
2021-09-21 13:31 ` Ken Brown
2021-09-21 15:36 ` Takashi Yano
2021-09-21 18:51 ` Ken Brown
2021-09-23 8:26 ` Takashi Yano
2021-09-23 13:03 ` Ken Brown
2021-09-23 15:03 ` Takashi Yano
2021-09-23 16:29 ` Ken Brown
2021-10-18 10:51 ` Corinna Vinschen
2021-10-18 12:02 ` Takashi Yano
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=YTEd031zU7k+26Uw@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-developers@cygwin.com \
/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: link
Be 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).