Mail Archives: cygwin/2021/08/27/07:25:53
| X-Recipient: | archive-cygwin AT delorie DOT com
|
| DKIM-Filter: | OpenDKIM Filter v2.11.0 sourceware.org 89847385AC3B
|
| DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
|
| s=default; t=1630063550;
|
| bh=2ziSY+4eqwBsifGzYSKezrGZ7QJNNyOYgW4/9Jo/E5E=;
|
| h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
|
| List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
|
| From;
|
| b=pZLqF1/x06h0QMo020HJ+ewQJvpa7ZV6PHyfESrnmJMYUwohzKvXzdo5BujZjok/7
|
| pa44Q5s4tmKe1K5J8y0zKhdX0HQbpmzyn1/7xrr94YYfsptcQcw0zKroKI88jkDXDd
|
| e+NVvGTabWtXCFtg0A3drGz4itJg9rbYlE5q1qjA=
|
| X-Original-To: | cygwin AT cygwin DOT com
|
| Delivered-To: | cygwin AT cygwin DOT com
|
| DMARC-Filter: | OpenDMARC Filter v1.4.1 sourceware.org 9E6F13857C60
|
| DKIM-Filter: | OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 17RBOcsK001556
|
| X-Nifty-SrcIP: | [110.4.221.123]
|
| Date: | Fri, 27 Aug 2021 20:24:40 +0900
|
| To: | cygwin AT cygwin DOT com
|
| Subject: | Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?
|
| Message-Id: | <20210827202440.47706fc2fc07c5e9a1bc0047@nifty.ne.jp>
|
| In-Reply-To: | <3b560051-ab27-f392-ca4b-d1fd9b5733b0@cornell.edu>
|
| References: | <41A583E1-C8E7-42AB-9F24-EEC33A41EC60 AT house DOT org>
|
| <20210825201845 DOT 07b6400b79dc5558a7761efe AT nifty DOT ne DOT jp>
|
| <f8106fe7-a2b8-d106-3061-4d888124f4b0 AT cornell DOT edu>
|
| <20210826062934 DOT 54f2f2216021c095bb7ba13b AT nifty DOT ne DOT jp>
|
| <d0a8c57d-1ed1-6b4f-c6e7-cbe0e2ec8a1c AT cornell DOT edu>
|
| <3b560051-ab27-f392-ca4b-d1fd9b5733b0 AT cornell DOT edu>
|
| X-Mailer: | Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
|
| Mime-Version: | 1.0
|
| X-Spam-Status: | No, score=-2.3 required=5.0 tests=BAYES_00, BODY_8BITS,
|
| DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A,
|
| RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
|
| TXREP autolearn=ham autolearn_force=no version=3.4.4
|
| X-Spam-Checker-Version: | SpamAssassin 3.4.4 (2020-01-24) on
|
| server2.sourceware.org
|
| X-BeenThere: | cygwin AT cygwin DOT com
|
| X-Mailman-Version: | 2.1.29
|
| List-Id: | General Cygwin discussions and problem reports <cygwin.cygwin.com>
|
| List-Unsubscribe: | <https://cygwin.com/mailman/options/cygwin>,
|
| <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
|
| List-Archive: | <https://cygwin.com/pipermail/cygwin/>
|
| List-Post: | <mailto:cygwin AT cygwin DOT com>
|
| List-Help: | <mailto:cygwin-request AT cygwin DOT com?subject=help>
|
| List-Subscribe: | <https://cygwin.com/mailman/listinfo/cygwin>,
|
| <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
|
| From: | Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
|
| Reply-To: | Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
|
| Errors-To: | cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
|
| Sender: | "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
|
This is a multi-part message in MIME format.
--Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thu, 26 Aug 2021 18:18:29 -0400
Ken Brown wrote:
> On 8/26/2021 11:56 AM, Ken Brown via Cygwin wrote:
> > On 8/25/2021 5:29 PM, Takashi Yano wrote:
> >> On Wed, 25 Aug 2021 13:52:19 -0400
> >> Ken Brown wrote:
> >>> On 8/25/2021 7:18 AM, Takashi Yano via Cygwin wrote:
> >>>> On Tue, 24 Aug 2021 12:49:52 -0700
> >>>> Chris Roehrig wrote:
> >>>>> I have a network of Windows, Linux and Mac machines and I use rsy=
nc to=20
> >>>>> synchronize various directories between them.
> >>>>>
> >>>>> I'm trying to figure out why my rsync transfers are so slow (<4 M=
B/s) only=20
> >>>>> when the remote endpoint is Cygwin rsync over sshd (with both a L=
inux or=20
> >>>>> Cygwin rsync client).=C2=A0=C2=A0 In all other scenarios, I get t=
he full 100MB/s as=20
> >>>>> expected from gigabit ethernet.=C2=A0 This has been an ongoing pr=
oblem for me=20
> >>>>> for a couple of years over several Windows and Cygwin versions, a=
nd I'd=20
> >>>>> like to try to fix it.
> >>>>>
> >>>>> If I run rsync --daemon --no-detach under mintty in the foregroun=
d on the=20
> >>>>> remote Windows endpoint,=C2=A0 I get the full 100 MB/s transfers,=
so it seems=20
> >>>>> like it has something to do with rsync.exe running in the backgro=
und under=20
> >>>>> the cygrunsrv+sshd service (which was installed normally using=20
> >>>>> ssh-host-config).
> >>>>>
> >>>>> If I do:
> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0pv /dev/zero | ssh $WINHOST "cat > /dev/n=
ull"
> >>>>> or even
> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0pv /dev/urandom | ssh $WINHOST md5sum
> >>>>> I also get the full 100 MB/s transfers, so it doesn't look like s=
shd itself=20
> >>>>> is being throttled by bandwidth or CPU.
> >>>>>
> >>>>> The machines have less than 15% CPU utilization while transferrin=
g, with=20
> >>>>> each of the 4 cores less than 30%, so it doesn't look to be CPU i=
ssue.
> >>>>> In Task Manager, sshd.exe and rsync.exe seem to be running normal=
ly using=20
> >>>>> only few percent CPU, and show Power Throttling=3DDisabled,=20
> >>>>> Priority=3DNormal.=C2=A0=C2=A0 Setting their Priority to High doe=
sn't seem to change=20
> >>>>> things.
> >>>>>
> >>>>> Looking in Resource Monitor on the remote endpoint, the network u=
sage is=20
> >>>>> pretty much a flat horizontal line at about 18 Mbps (2.5 MB/s), s=
o it sure=20
> >>>>> looks to me as if rsync is somehow being bandwidth-throttled=08 w=
hen run in=20
> >>>>> the background under cygsshd.
> >>>>>
> >>>>> It's almost as if rsync has an implicit --bwlimit override when i=
t is run=20
> >>>>> from cygrunsrv+sshd (I've tried --bwlimit=3D0 on the client which=
makes no=20
> >>>>> difference).
> >>>>>
> >>>>>
> >>>>> Any ideas?=C2=A0=C2=A0=C2=A0 Not sure where to go from here.
> >>>>
> >>>> In cygwin, just scp is very slow.
> >>>>
> >>>> The transfer speed in my environment is as follows.
> >>>> The tests were done with 100MB of test.dat file.
> >>>>
> >>>> (1-1) From cygwin-PC,
> >>>> [yano AT cygwin-PC ~]$ scp test.dat yano AT linux-server:.
> >>>> yano AT linux-server's password:
> >>>> test.dat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 100%=C2=A0 100MB=C2=A0=C2=A0 4.0MB/s=C2=A0=C2=A0 00:24
> >>>> [yano AT cygwin-PC ~]$ scp yano AT linux-server:test.dat .
> >>>> yano AT linux-server's password:
> >>>> test.dat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 100%=C2=A0 100MB=C2=A0=C2=A0 8.0MB/s=C2=A0=C2=A0 00:12
> >>>>
> >>>> (1-2) From linux-server,
> >>>> yano AT linux-server:~$ scp yano AT cygwin-PC:test.dat .
> >>>> yano AT cygwin-PC's password:
> >>>> test.dat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 100%=C2=A0 100MB=C2=A0=C2=A0 4.0MB/s=C2=A0=C2=A0 00:24
> >>>> yano AT linux-server:~$ scp test.dat yano AT cygwin-PC:.
> >>>> yano AT cygwin-PC's password:
> >>>> test.dat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 100%=C2=A0 100MB=C2=A0=C2=A0 4.1MB/s=C2=A0=C2=A0 00:24
> >>>>
> >>>>
> >>>> I looked into this problem, and noticed that this is caused
> >>>> by cygwin pipe implementation. Pipe in cygwin is configured
> >>>> with FILE_FLAG_OVERLAPPED.
> >>>>
> >>>> If the pipe is configured without FILE_FLAG_OVERLAPPED,
> >>>> the transfer speed is much improved as follows.
> >>>>
> >>>>
> >>>> (2-1) From cygwin-PC,
> >>>> [yano AT cygwin-PC ~]$ scp test.dat yano AT linux-server:.
> >>>> yano AT linux-server's password:
> >>>> test.dat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 100%=C2=A0 100MB=C2=A0 85.5MB/s=C2=A0=C2=A0 00:01
> >>>> [yano AT cygwin-PC ~]$ scp yano AT linux-server:test.dat .
> >>>> yano AT linux-server's password:
> >>>> test.dat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 100%=C2=A0 100MB=C2=A0 69.7MB/s=C2=A0=C2=A0 00:01
> >>>>
> >>>> (2-2) From linux-server,
> >>>> yano AT linux-server:~$ scp yano AT cygwin-PC:test.dat .
> >>>> yano AT cygwin-PC's password:
> >>>> test.dat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 100%=C2=A0 100MB=C2=A0 80.1MB/s=C2=A0=C2=A0 00:01
> >>>> yano AT linux-server:~$ scp test.dat yano AT cygwin-PC:.
> >>>> yano AT cygwin-PC's password:
> >>>> test.dat=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 100%=C2=A0 100MB=C2=A0 57.7MB/s=C2=A0=C2=A0 00:01
> >>>>
> >>>> I am not sure why this happens and how to fix this.
> >>>
> >>> A couple years ago I had an idea for changing the pipe implementati=
on to avoid
> >>> overlapped I/O:
> >>>
> >>> =C2=A0=C2=A0=C2=A0 https://cygwin.com/pipermail/cygwin-patches/2019=
q2/009393.html
> >>> =C2=A0=C2=A0=C2=A0 https://cygwin.com/pipermail/cygwin-patches/2019=
q2/009423.html
> >>>
> >>> I never followed up on it.=C2=A0 But if you think it might help wit=
h this problem, I
> >>> could dust it off and try to finish it.
> >>
> >> Interesting.
> >>
> >> It will be also helpfull for:
> >> https://cygwin.com/pipermail/cygwin/2021-March/247987.html
> >> which seems to be the same issue with
> >> https://stackoverflow.com/questions/10385424/good-alternatives-to-cy=
gwin-cygwin-doesnt-support-natively-support-win32-app=20
> >>
> >>
> >> However, I wonder why scp dislikes overlapped I/O.
> >=20
> > I agree that it would be good to understand this.=C2=A0 When I first =
proposed the=20
> > change, I was thinking in terms of code simplification.=C2=A0 If it a=
lso improves=20
> > performance (which we don't know yet), it becomes a higher priority, =
but in that=20
> > case it would be nice to understand why it improves performance.
>=20
> Hi Takashi,
>=20
> In case you want to try out my proposed change, I've just rebased the p=
atches to=20
> the current master and pushed them to a new topic/pipe branch.
Hi Ken,
Thanks much! I tested topic/pipe branch.
[yano AT cygwin-PC ~]$ scp test.dat yano AT linux-server:.
yano AT linux-server's password:
test.dat 100% 100MB 95.9MB/s 00:=
01
[yano AT cygwin-PC ~]$ scp yano AT linux-server:test.dat .
yano AT linux-server's password:
test.dat 100% 100MB 8.0MB/s 00:=
12
yano AT linux-server:~$ scp yano AT cygwin-PC:test.dat .
yano AT cygwin-PC's password:
test.dat 100% 100MB 109.7MB/s 00:=
00
yano AT linux-server:~$ scp test.dat yano AT cygwin-PC:.
yano AT cygwin-PC's password:
test.dat 100% 100MB 31.4MB/s 00:=
03
As shown above, outgoing transfer-rate has been improved upto near
theoretical limit. However, incoming transfer-rate is not improved
much.
I digged further and found the first patch attached solves the issue
as follows.
[yano AT cygwin-PC ~]$ scp yano AT linux-server:test.dat .
yano AT linux-server's password:
test.dat 100% 100MB 112.8MB/s 00:=
00
yano AT linux-server2:~$ scp test.dat yano AT cygwin-PC:.
yano AT cygwin-PC's password:
test.dat 100% 100MB 102.5MB/s 00:=
00
I also tested the case:
> >> https://cygwin.com/pipermail/cygwin/2021-March/247987.html
> >> which seems to be the same issue with
> >> https://stackoverflow.com/questions/10385424/good-alternatives-to-cy=
gwin-cygwin-doesnt-support-natively-support-win32-app
Unfortunately, topic/pipe does not help.
I confirmed that applying the second patch attached, which reverts
to create() rather than nt_create(), and setting CYGWIN=3Dpipe_byte
fixes the problem.
What do you think of this alternative implementation which does
not use nt_create()?
--=20
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
--Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F
Content-Type: application/octet-stream;
name="0001-Cygwin-select-Improve-select-poll-response.patch"
Content-Disposition: attachment;
filename="0001-Cygwin-select-Improve-select-poll-response.patch"
Content-Transfer-Encoding: base64
RnJvbSBjMmVjZWNlYTczMWZiNjMzYTllMTA2NjZkNzU0NmUxYzYxYzhjNGY3IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBUYWthc2hpIFlhbm8gPHRha2FzaGkueWFub0BuaWZ0eS5uZS5q
cD4KRGF0ZTogRnJpLCAyNyBBdWcgMjAyMSAxOTo1NDo0MSArMDkwMApTdWJqZWN0OiBbUEFUQ0gg
MS8yXSBDeWd3aW46IHNlbGVjdDogSW1wcm92ZSBzZWxlY3QvcG9sbCByZXNwb25zZS4KCi0tLQog
d2luc3VwL2N5Z3dpbi9zZWxlY3QuY2MgfCAzMiArKysrKysrKysrKysrKysrKysrKysrKysrKysr
LS0tLQogMSBmaWxlIGNoYW5nZWQsIDI4IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pCgpk
aWZmIC0tZ2l0IGEvd2luc3VwL2N5Z3dpbi9zZWxlY3QuY2MgYi93aW5zdXAvY3lnd2luL3NlbGVj
dC5jYwppbmRleCA4YWQ5ODJjMTIuLjgzZTFjMDBlMCAxMDA2NDQKLS0tIGEvd2luc3VwL2N5Z3dp
bi9zZWxlY3QuY2MKKysrIGIvd2luc3VwL2N5Z3dpbi9zZWxlY3QuY2MKQEAgLTczNSw2ICs3MzUs
NyBAQCB0aHJlYWRfcGlwZSAodm9pZCAqYXJnKQogICBzZWxlY3RfcGlwZV9pbmZvICpwaSA9IChz
ZWxlY3RfcGlwZV9pbmZvICopIGFyZzsKICAgRFdPUkQgc2xlZXBfdGltZSA9IDA7CiAgIGJvb2wg
bG9vcGluZyA9IHRydWU7CisgIERXT1JEIHQwID0gR2V0VGlja0NvdW50ICgpOwogCiAgIHdoaWxl
IChsb29waW5nKQogICAgIHsKQEAgLTc1NCw3ICs3NTUsMTIgQEAgdGhyZWFkX3BpcGUgKHZvaWQg
KmFyZykKIAlicmVhazsKICAgICAgIGN5Z3dhaXQgKHBpLT5ieWUsIHNsZWVwX3RpbWUgPj4gMyk7
CiAgICAgICBpZiAoc2xlZXBfdGltZSA8IDgwKQotCSsrc2xlZXBfdGltZTsKKwl7CisJICBEV09S
RCB0MSA9IEdldFRpY2tDb3VudCAoKTsKKwkgIGlmICh0MCAhPSB0MSkKKwkgICAgKytzbGVlcF90
aW1lOworCSAgdDAgPSB0MTsKKwl9CiAgICAgICBpZiAocGktPnN0b3BfdGhyZWFkKQogCWJyZWFr
OwogICAgIH0KQEAgLTkzMCw2ICs5MzYsNyBAQCB0aHJlYWRfZmlmbyAodm9pZCAqYXJnKQogICBz
ZWxlY3RfZmlmb19pbmZvICpwaSA9IChzZWxlY3RfZmlmb19pbmZvICopIGFyZzsKICAgRFdPUkQg
c2xlZXBfdGltZSA9IDA7CiAgIGJvb2wgbG9vcGluZyA9IHRydWU7CisgIERXT1JEIHQwID0gR2V0
VGlja0NvdW50ICgpOwogCiAgIHdoaWxlIChsb29waW5nKQogICAgIHsKQEAgLTk0OSw3ICs5NTYs
MTIgQEAgdGhyZWFkX2ZpZm8gKHZvaWQgKmFyZykKIAlicmVhazsKICAgICAgIGN5Z3dhaXQgKHBp
LT5ieWUsIHNsZWVwX3RpbWUgPj4gMyk7CiAgICAgICBpZiAoc2xlZXBfdGltZSA8IDgwKQotCSsr
c2xlZXBfdGltZTsKKwl7CisJICBEV09SRCB0MSA9IEdldFRpY2tDb3VudCAoKTsKKwkgIGlmICh0
MCAhPSB0MSkKKwkgICAgKytzbGVlcF90aW1lOworCSAgdDAgPSB0MTsKKwl9CiAgICAgICBpZiAo
cGktPnN0b3BfdGhyZWFkKQogCWJyZWFrOwogICAgIH0KQEAgLTExMjUsNiArMTEzNyw3IEBAIHRo
cmVhZF9jb25zb2xlICh2b2lkICphcmcpCiAgIHNlbGVjdF9jb25zb2xlX2luZm8gKmNpID0gKHNl
bGVjdF9jb25zb2xlX2luZm8gKikgYXJnOwogICBEV09SRCBzbGVlcF90aW1lID0gMDsKICAgYm9v
bCBsb29waW5nID0gdHJ1ZTsKKyAgRFdPUkQgdDAgPSBHZXRUaWNrQ291bnQgKCk7CiAKICAgd2hp
bGUgKGxvb3BpbmcpCiAgICAgewpAQCAtMTE0NCw3ICsxMTU3LDEyIEBAIHRocmVhZF9jb25zb2xl
ICh2b2lkICphcmcpCiAJYnJlYWs7CiAgICAgICBjeWd3YWl0IChjaS0+YnllLCBzbGVlcF90aW1l
ID4+IDMpOwogICAgICAgaWYgKHNsZWVwX3RpbWUgPCA4MCkKLQkrK3NsZWVwX3RpbWU7CisJewor
CSAgRFdPUkQgdDEgPSBHZXRUaWNrQ291bnQgKCk7CisJICBpZiAodDAgIT0gdDEpCisJICAgICsr
c2xlZXBfdGltZTsKKwkgIHQwID0gdDE7CisJfQogICAgICAgaWYgKGNpLT5zdG9wX3RocmVhZCkK
IAlicmVhazsKICAgICB9CkBAIC0xMzY0LDYgKzEzODIsNyBAQCB0aHJlYWRfcHR5X3NsYXZlICh2
b2lkICphcmcpCiAgIHNlbGVjdF9waXBlX2luZm8gKnBpID0gKHNlbGVjdF9waXBlX2luZm8gKikg
YXJnOwogICBEV09SRCBzbGVlcF90aW1lID0gMDsKICAgYm9vbCBsb29waW5nID0gdHJ1ZTsKKyAg
RFdPUkQgdDAgPSBHZXRUaWNrQ291bnQgKCk7CiAKICAgd2hpbGUgKGxvb3BpbmcpCiAgICAgewpA
QCAtMTM4Myw3ICsxNDAyLDEyIEBAIHRocmVhZF9wdHlfc2xhdmUgKHZvaWQgKmFyZykKIAlicmVh
azsKICAgICAgIGN5Z3dhaXQgKHBpLT5ieWUsIHNsZWVwX3RpbWUgPj4gMyk7CiAgICAgICBpZiAo
c2xlZXBfdGltZSA8IDgwKQotCSsrc2xlZXBfdGltZTsKKwl7CisJICBEV09SRCB0MSA9IEdldFRp
Y2tDb3VudCAoKTsKKwkgIGlmICh0MCAhPSB0MSkKKwkgICAgKytzbGVlcF90aW1lOworCSAgdDAg
PSB0MTsKKwl9CiAgICAgICBpZiAocGktPnN0b3BfdGhyZWFkKQogCWJyZWFrOwogICAgIH0KLS0g
CjIuMzMuMAoK
--Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F
Content-Type: application/octet-stream;
name="0002-Cygwin-pipe-Revert-to-create-rather-than-nt_create.patch"
Content-Disposition: attachment;
filename="0002-Cygwin-pipe-Revert-to-create-rather-than-nt_create.patch"
Content-Transfer-Encoding: base64
RnJvbSA3ODQ4OTJkYzI3MmE2Yjc4OTlkZTVmODljNjViYjhjZmFiNzk1OTFkIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBUYWthc2hpIFlhbm8gPHRha2FzaGkueWFub0BuaWZ0eS5uZS5q
cD4KRGF0ZTogRnJpLCAyNyBBdWcgMjAyMSAyMDowNjowNCArMDkwMApTdWJqZWN0OiBbUEFUQ0gg
Mi8yXSBDeWd3aW46IHBpcGU6IFJldmVydCB0byBjcmVhdGUoKSByYXRoZXIgdGhhbiBudF9jcmVh
dGUoKS4KCi0tLQogd2luc3VwL2N5Z3dpbi9maGFuZGxlcl9waXBlLmNjIHwgMjQgKysrKysrKysr
KysrKysrKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgMjMgaW5zZXJ0aW9ucygrKSwgMSBkZWxl
dGlvbigtKQoKZGlmZiAtLWdpdCBhL3dpbnN1cC9jeWd3aW4vZmhhbmRsZXJfcGlwZS5jYyBiL3dp
bnN1cC9jeWd3aW4vZmhhbmRsZXJfcGlwZS5jYwppbmRleCAyZGVjMGE4NDguLmIzYWY0YTBhMCAx
MDA2NDQKLS0tIGEvd2luc3VwL2N5Z3dpbi9maGFuZGxlcl9waXBlLmNjCisrKyBiL3dpbnN1cC9j
eWd3aW4vZmhhbmRsZXJfcGlwZS5jYwpAQCAtMjM0LDYgKzIzNCwyNCBAQCBmaGFuZGxlcl9waXBl
OjpyYXdfcmVhZCAodm9pZCAqcHRyLCBzaXplX3QmIGxlbikKICAgICAgIHJldHVybjsKICAgICB9
CiAKKyAgaWYgKGlzX25vbmJsb2NraW5nICgpKQorICAgIHsKKyAgICAgIERXT1JEIG47CisgICAg
ICBCT09MIHJldCA9IFBlZWtOYW1lZFBpcGUgKGdldF9oYW5kbGUgKCksIE5VTEwsIDAsIE5VTEws
ICZuLCBOVUxMKTsKKyAgICAgIGlmICghcmV0KQorCXsKKwkgIF9fc2V0ZXJybm8gKCk7CisJICBs
ZW4gPSAoc2l6ZV90KSAtMTsKKwkgIHJldHVybjsKKwl9CisgICAgICBpZiAobiA9PSAwKQorCXsK
KwkgIHNldF9lcnJubyAoRUFHQUlOKTsKKwkgIGxlbiA9IChzaXplX3QpIC0xOworCSAgcmV0dXJu
OworCX0KKyAgICB9CisKICAgZG8KICAgICB7CiAgICAgICBsZW4gPSBvcmlnX2xlbjsKQEAgLTU3
MSw2ICs1ODksNyBAQCBmaGFuZGxlcl9waXBlOjpjcmVhdGUgKExQU0VDVVJJVFlfQVRUUklCVVRF
UyBzYV9wdHIsIFBIQU5ETEUgciwgUEhBTkRMRSB3LAogICByZXR1cm4gMDsKIH0KIAorI2lmIDAK
IC8qIFRoZSBuZXh0IHZlcnNpb24gb2YgZmhhbmRsZXJfcGlwZTo6Y3JlYXRlIHVzZWQgdG8gY2Fs
bCB0aGUgcHJldmlvdXMKICAgIHZlcnNpb24uICBCdXQgdGhlIHJlYWQgaGFuZGxlIGNyZWF0ZWQg
YnkgdGhlIGxhdHRlciBkb2Vzbid0IGhhdmUKICAgIEZJTEVfV1JJVEVfQVRUUklCVVRFUyBhY2Nl
c3MgdW5sZXNzIHRoZSBwaXBlIGlzIGNyZWF0ZWQgd2l0aApAQCAtNTg4LDYgKzYwNyw3IEBAIGZo
YW5kbGVyX3BpcGU6OmNyZWF0ZSAoTFBTRUNVUklUWV9BVFRSSUJVVEVTIHNhX3B0ciwgUEhBTkRM
RSByLCBQSEFORExFIHcsCiAKIHN0YXRpYyBpbnQgbnRfY3JlYXRlIChMUFNFQ1VSSVRZX0FUVFJJ
QlVURVMsIFBIQU5ETEUsIFBIQU5ETEUsIERXT1JELAogCQkgICAgICBpbnQ2NF90ICopOworI2Vu
ZGlmCiAKIGludAogZmhhbmRsZXJfcGlwZTo6Y3JlYXRlIChmaGFuZGxlcl9waXBlICpmaHNbMl0s
IHVuc2lnbmVkIHBzaXplLCBpbnQgbW9kZSkKQEAgLTU5Nyw3ICs2MTcsNyBAQCBmaGFuZGxlcl9w
aXBlOjpjcmVhdGUgKGZoYW5kbGVyX3BpcGUgKmZoc1syXSwgdW5zaWduZWQgcHNpemUsIGludCBt
b2RlKQogICBpbnQgcmVzID0gLTE7CiAgIGludDY0X3QgdW5pcXVlX2lkOwogCi0gIGludCByZXQg
PSBudF9jcmVhdGUgKHNhLCAmciwgJncsIHBzaXplLCAmdW5pcXVlX2lkKTsKKyAgaW50IHJldCA9
IGNyZWF0ZSAoc2EsICZyLCAmdywgcHNpemUsIE5VTEwsIDAsICZ1bmlxdWVfaWQpOwogICBpZiAo
cmV0KQogICAgIF9fc2V0ZXJybm9fZnJvbV93aW5fZXJyb3IgKHJldCk7CiAgIGVsc2UgaWYgKChm
aHNbMF0gPSAoZmhhbmRsZXJfcGlwZSAqKSBidWlsZF9maF9kZXYgKCpwaXBlcl9kZXYpKSA9PSBO
VUxMKQpAQCAtNjI0LDYgKzY0NCw3IEBAIGZoYW5kbGVyX3BpcGU6OmNyZWF0ZSAoZmhhbmRsZXJf
cGlwZSAqZmhzWzJdLCB1bnNpZ25lZCBwc2l6ZSwgaW50IG1vZGUpCiAgIHJldHVybiByZXM7CiB9
CiAKKyNpZiAwCiBzdGF0aWMgaW50CiBudF9jcmVhdGUgKExQU0VDVVJJVFlfQVRUUklCVVRFUyBz
YV9wdHIsIFBIQU5ETEUgciwgUEhBTkRMRSB3LAogCQlEV09SRCBwc2l6ZSwgaW50NjRfdCAqdW5p
cXVlX2lkKQpAQCAtNzU1LDYgKzc3Niw3IEBAIG50X2NyZWF0ZSAoTFBTRUNVUklUWV9BVFRSSUJV
VEVTIHNhX3B0ciwgUEhBTkRMRSByLCBQSEFORExFIHcsCiAgIC8qIFN1Y2Nlc3MuICovCiAgIHJl
dHVybiAwOwogfQorI2VuZGlmCiAKIGludAogZmhhbmRsZXJfcGlwZTo6aW9jdGwgKHVuc2lnbmVk
IGludCBjbWQsIHZvaWQgKnApCi0tIAoyLjMzLjAKCg==
--Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--
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
--Multipart=_Fri__27_Aug_2021_20_24_40_+0900_lf.Jf5F5Tm0BrY/F--
- Raw text -