From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by sourceware.org (Postfix) with ESMTPS id 564033851C39 for ; Wed, 4 Nov 2020 12:03:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 564033851C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=corinna-cygwin@cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Myb09-1kQZHB3dDp-00yy5M for ; Wed, 04 Nov 2020 13:03:04 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 57EDBA80DE8; Wed, 4 Nov 2020 13:03:04 +0100 (CET) Date: Wed, 4 Nov 2020 13:03:04 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: AF_UNIX status report Message-ID: <20201104120304.GF33165@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <1d0ea5dc-7e9b-d8fe-5f6e-da7a799a3b13@cornell.edu> <20201027094340.GJ5492@calimero.vinschen.de> <0f945b4c-aa30-e08e-9f86-d4b41279ba10@pismotec.com> <20201030092019.GW5492@calimero.vinschen.de> <38e33f7a-e87d-fea8-ac9e-826f94c189d4@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <38e33f7a-e87d-fea8-ac9e-826f94c189d4@cornell.edu> X-Provags-ID: V03:K1:IMiMqXaOacZOlfLtYRnc8QyAWVqgkAmrejOYsdXKrJpPWA9+SDA +zILf1uJC+rd7F7EkbqDZw+RaOQg9pX42a0ov2NDu+oF5xUd8AImkaFYGOgc1urK5jLXXXa wW0TWG8tuoAn2sHszZ4s0RFsF9qfkJCJqOOqVIiPyXx+WbGShYU8LpDqx2D+TQ0ZWhWVfQr LKB+ouU6N2eOpoettKPKw== X-UI-Out-Filterresults: notjunk:1;V03:K0:SkjPTodfKJA=:nC9ZBWMDJjcZmxohvJzxfV 6uDZakHfkpx+d4+9ataUzMsfo205o+NK6xdvwZE5INc/CrnxagXj7uQvYnS7aTeuA04VYzPVm 9ks29CRgoU6UZ2PrM3x8Qn4pGAlsl127xdNn1fOkRYlGw3960B0WRoS7LI2JbpC1EW/tv/yhe 7wuS+IyatWePvkGDKHq934BlHQuiA0XkzVGIKnQOi0jQe3+wLAarE/pf9Q1z3qVSMQc6F3ege +jaImZDTAJk3txnEu0WOnvgiCQusUIOdzpRRkRfr0EWsNfNHXD58KvoXtNe27EBhcF2qH9ywS xVERgPAbalDDwUFzQVQQsbr3EnIqItxmih0HQfiJ0couHho04hDTUzEzgDK+MTAasf+6x+pr4 sqiN1IHd5N4l6Ncp9M5TQDDZddRr0ph7RUUUQfNboLDGT7IVehWJYNRD3E/gjNRrhuSK9opGO oja21ExqvA== X-Spam-Status: No, score=-100.7 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 04 Nov 2020 12:03:11 -0000 On Nov 3 10:43, Ken Brown via Cygwin-developers wrote: > On 10/30/2020 5:20 AM, Corinna Vinschen wrote: > > On Oct 29 14:53, Joe Lowe wrote: > > > On 2020-10-29 13:19, Ken Brown via Cygwin-developers wrote: > > > > On 10/27/2020 5:43 AM, Corinna Vinschen wrote: > > > > > On Oct 26 18:04, Ken Brown via Cygwin-developers wrote: > > > > > > 2. I haven't given any thought at all as to how to implement SCM_RIGHTS > > > > > > ancillary data.  I could definitely use suggestions on that > > > > > > before I start > > > > > > thrashing around. > > > > > > > > > > I have only vague ideas at that point.  Assuming we can replace the > > > > > socket implemantation with the pipe implementation, what we have is a > > > > > pipe which can impersonate the peer at least from the server side, and > > > > > it knows the client process.  This in turn can be used to duplicate > > > > > handles.  So what we could do is to define fhandler methods which create > > > > > a matching serialization  and deserialization of the fhandler data, plus > > > > > duplicating the handles for the other process, sent over the pipe as > > > > > admin package.  This must work in either direction, regardless if the > > > > > server or the client sends the SCM_RIGHTS block. > > > > > > > > This sounds reasonable. > > > > > > > > I have no experience with serialization.  Do you happen to know of a > > > > good example that I could look at? > > > > Unfortunately not. Probably we can just send the entire fhandler and > > the recipient fiddles the content in a per-class way, kind of like > > fhandler::dup. > > I'm working on implementing this, and I've bumped into an elementary C++ > question. In order to send the fhandler in an admin packet, I need to > determine its size dynamically, given an (fhandler_base *) pointer to it. > AFAICS, this requires something like the following. > > In the definition of class fhandler_base, put a virtual function > > virtual size_t size () const { return sizeof *this; } > > and then repeat this essentially verbatim in every derived class: > > size_t size () const { return sizeof *this; } > > Does this seem right? I did an internet search and didn't find anything > substantially different, although there were several suggestions to use > templates in various ways. I'm not convinced that using templates would > actually improve the code, but I can do it if you think it's better. Actually, I don't like templates that much. You could do the above, or just always send a block of size fhandler_union. Corinna