From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by sourceware.org (Postfix) with ESMTPS id 38167384F02A for ; Wed, 8 Sep 2021 18:28:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 38167384F02A Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M2ON6-1mNV923eAQ-003xYz for ; Wed, 08 Sep 2021 20:28:42 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 12B44A80D9E; Wed, 8 Sep 2021 20:28:42 +0200 (CEST) Date: Wed, 8 Sep 2021 20:28:42 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled? Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <24138e20-aa97-cfea-bf48-198fc67755ea@cornell.edu> <9ba687eb-f4a0-18f8-b10b-76e7e51e123e@cornell.edu> <152bfc0c-2f72-c684-6fc5-aa7c36c136b8@cornell.edu> <20210908203234.8cc6215e05108d9ad0507bd3@nifty.ne.jp> <9207824e-bd76-d99c-8801-b42fdbcb4d17@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9207824e-bd76-d99c-8801-b42fdbcb4d17@cornell.edu> X-Provags-ID: V03:K1:hrUt+qj2gt3C1SO5HJE2BBApvipghbrWqX3i+dHAuFDZEP5iqq1 Zs3KGFqha5/AMEvYgvUAVsr9Th8L4Eohc8CVCNYZZ5qIoaY4jIaDKKWS9a4UkLzYA7j6PZg 9RQjA40kcu/4xKPlPEaYbPKvUOmBcMjgkKhTa1ECdN31wUDlPNEvBTwEZUFKnMJjTXjfgJ5 +Uu0+8IomgnOAJmHsjMhQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:VC3cZYbxQNE=:KvOtSy+lBBj+Qo/kp4IyTB gOgypmgnMcUecwA6W0YJSlH40fH8xNgz+Jq2zgVtw9sJ+QMuZ9SivsymOH+X02+QoL1KpF4EP ag+pwZTPI/ky1POI2zBnIZT8uDK3I2nmC8gns0J937zueocHOQ1mm4OHFazJBwXwe8YaBrG3N qjOmhlQ9VZkFGEpU1iq+dc4ySg6ADFMAQ8N12Ag8a8lYFepgrgTRLYDJnExiuq23QWa1a6Byh pcoKdADN61OzM8qcNJ16XQ4MGv+d89Nd9OfiJPqH4uybktxXp6HABHnzrSYnGvxWSETHvSHLj LIoTMIz1djGKKJ+lpi6Vlg0QwEJ03xafC+aVG47anywU1VD3sYhaslT1PItQ88WOhAoshIZQp YCqiJ+5plEGnjhZITx8Yta+Pb1Q9wOL5zdLUacelYYR4L2vpFR6fXbAjI/rn3gmUGmME+Sqnz 6374tnteHGVCorzYALwmvKuWaazQPTDLB/3S/+5LKtud778vlkn+IiEYLWcykPhoIogQhDaGk Ewe8KJL7cE4Nru3tlwVO+0/demD4izRqbxh5mYmE0r3b1kPEznZ/1nbW8JxDSVUemCh0bhSpU okbxRO8r1lhilCU6PEU87zX6v69HPmMH3RU//fKSDnGEyuyUHoMFIx23qVTbbpRkxZ8MHBRYK /r/t82k8OdYP0kEKn1a8LGn4K5vAZ0c6DJPZBMZifeSR6dR2bjmCBUHxzrx1nxPJNEsH0Xyce ZNL52ExA/aroY9cmLxk8i8itJPtSMq9UvdThplHf2JT8W6mmEhSaktTxuJE= X-Spam-Status: No, score=-99.9 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, 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-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 18:28:46 -0000 On Sep 8 13:43, Ken Brown wrote: > On 9/8/2021 7:55 AM, Corinna Vinschen wrote: > > On Sep 8 20:32, Takashi Yano wrote: > > > As for this patch, read_mtx was introduced. This handle is initialized > > > only for read pipe. However, this seems to be NULL even without > > > initialization in write pipe. I wonder why initializing read_mtx in > > > the constructor is not necessary. > > > > > > How do you guarantee that read_mtx is NULL on the write pipe? > > > > fhandlers are always calloc'ed on the cygheap, so you don't have > > to initialize anything to NULL. It doesn't hurt, of course, but > > it's certainly not required. > > Takashi and I both asked this question, and you had to answer it twice. > It's likely that future readers of the code will ask it again. Yes, but ... it's not hidden knowledge. You're using the function build_fh_dev. Looking into dtable.cc shows build_fh_dev calls build_fh_pc which in turn calls fh_alloc. fh_alloc uses the cnew macro, defined in the same file, which resolves into void* ptr = (void*) ccalloc (HEAP_FHANDLER, 1, sizeof (fhandler_pipe)); new (ptr) fhandler_pipe (...); So the constructor is called on a memory slot on the cygheap, allocated with ccalloc, the cygheap equivalent to calloc on the user heap. > Would you be > amenable to a code cleanup patch that answers it once and for all? I would > suggest (a) removing all 0/NULL initializers from fhandler constructors and > (b) adding comments explaining why they're not needed. a) ok b) Commenting on the same issue in every single fhandler_* file appears a bit excessive, IMHO. Only one comment in fhandler.h should suffice. Corinna