From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) by sourceware.org (Postfix) with ESMTPS id 495B03950C61 for ; Tue, 4 May 2021 11:06:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 495B03950C61 Authentication-Results: sourceware.org; dmarc=fail (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 (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MbBUc-1l70yh37dI-00bYPY for ; Tue, 04 May 2021 13:06:43 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 2D4B8A80DB4; Tue, 4 May 2021 13:06:43 +0200 (CEST) Date: Tue, 4 May 2021 13:06:43 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: The unreliability of AF_UNIX datagram sockets Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <16e1d55e-15ea-6c0e-04e4-aa6cb2c0c1bd@cornell.edu> <5564e10e-9099-fc5a-3a8d-c2ffb8ca4cff@cornell.edu> <41fde522-4d14-a957-96ad-c5eaa0e0a801@cornell.edu> <1aa91ec3-ae10-0e83-470d-a8a2dcfd83b0@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1aa91ec3-ae10-0e83-470d-a8a2dcfd83b0@cornell.edu> X-Provags-ID: V03:K1:/ywCpVmAK4qhn0Wx8L5xIqk6lL6zU+I7qHnFVKbEKjP1TxMIoYJ LRIugghITqdwrnQOmiXg17Tydnc0YbBmK4DiGhPaRvgYLpZiSdMFQ604DL/P39/XUEZBcDe MgnSNOZDpfsmUutSbpH4rNxo5BaOa7NGSNyl6/EMQvL+3SZX46hm+M1WDhUi//SXkTHF0zM uw2VQGrDewHH5TrOHA3tw== X-UI-Out-Filterresults: notjunk:1;V03:K0:jkjhyhpgHjc=:Djk/4SRFLiAAUCUgEi9FRk ZGJkKJQUdbVqINe1C3X+j7BtBQKtbX3eF11gP/ZZTHYU4EFweoq8y/C+r5IDYG1ezRImO41Zt ubXkyTLSLfFwk+Dtg23dVlzPp3lUOG7Ed/ushbeJkD+ylxVCvpGTJMuEgeQzmoCS3Dc7VeJ23 CxJWu70qD7Zc0Lz7PWzu/o4P8X6QpnpJplZuR2T3K31ZKoxRWVPzXI0rswPizg3bvfKAD7cUh 3l02u4IVVP5AE5Dmel2fGd4HBc6Q4ZdESAnXHvU2Tg6CTjrb+g9keCCBJEKUGK3cW3tsbH4bM 4DvX5J3MFs1k8+baCwoQdXznWbfo1QvP5v3PlM4j0j7FgSIxYsM4DoJYFSgwd+b+xcwYCMrlW rtCF3v2AR52h2HsrRBwMX84PfE9CrO1su7zPSwPJXjQ1uJSH0qIaaFaUvNfDTZoYQq4EGRcuU 3jN8jezihSJGCVzYoTrXh2Kff7oD9/cVYu9mPEwi+YIZx3cHorf9R+NDYEX91/78v0mcmw7U4 OTwea3CqqXX66UZBFZ7VLs= X-Spam-Status: No, score=-98.8 required=5.0 tests=BAYES_00, BODY_8BITS, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Tue, 04 May 2021 11:06:47 -0000 On May 3 16:50, Ken Brown wrote: > On 5/3/2021 3:48 PM, Ken Brown wrote: > > On 5/3/2021 2:40 PM, Corinna Vinschen wrote: > > > On May  3 12:56, Ken Brown wrote: > > > > On 5/3/2021 11:45 AM, Corinna Vinschen wrote: > > > > > 7. The idea of _mq_recv partial reads is entirely broken.  Given that > > > > >      the information in the queue consists of header info plus payload, > > > > >      the entire block has to be read, and then a new block with fixed > > > > >      header and shortened payload has to be rewritten with bumped priority. > > > > >      This in turn can only be performed by the AF_UNIX code, unless we > > > > >      expect knowledge of the AF_UNIX packet layout in the mqueue code. > > > > > > > > The partial read is actually OK as is, since it's comparable to what happens > > > > on a partial read from a pipe.  I already have AF_UNIX code (on the > > > > topic/af_unix branch) that deals with that.  A boolean variable _unread > > > > keeps track of whether there's unread data from a previous partial read.  If > > > > so, the next read just reads data without expecting a header. > > > > > > Ok, never mind. > > > > > > One advantage of the mqueue when utilized as above would be that this > > > kind of state info is not required.  The content of a packet would > > > always be self-contained and bumping the priority would automagically > > > move the packet content to the top of the queue.  But that's just > > > idle musing at this point. > > > > I thought about that but rejected it for the following reason: Suppose > > the receiver reads a message and tries to rewrite it with modified > > header, shortened payload, and bumped priority.  The sender might have > > already written more messages between the read and the write, and the > > queue could be full. > > > > Now that I'm rethinking this, however, maybe we could get around that > > problem with an internal _mq_lock function that would block senders > > while the receiver decides whether it needs to do a partial read. > > Alternatively, _mq_recv could accept an _MQ_LOCK flag, which means "don't > release the mutex", and then there could be an _mq_unlock function, which > simply releases the mutex. That's an idea. However, I think this is something we can push back for now, and ultimately we can use any of the above solutions which makes most sense. Implemanting a defered unlock if required is not much of a problem. Corinna