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 3309D386102F for ; Tue, 6 Apr 2021 14:20:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3309D386102F 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 (mreue108 [212.227.15.183]) with ESMTPSA (Nemesis) id 1Mn2iP-1lu0Im2dfj-00k6fh for ; Tue, 06 Apr 2021 16:20:43 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 01408A80773; Tue, 6 Apr 2021 16:20:43 +0200 (CEST) Date: Tue, 6 Apr 2021 16:20:42 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: Questions about select for sockets Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <6b50ec89-5c02-c49f-ad85-e581589d21d3@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6b50ec89-5c02-c49f-ad85-e581589d21d3@cornell.edu> X-Provags-ID: V03:K1:TKNgV07if93D0qe2MICJkjIaMFFCXsGgMUjsvAnjyZIt5v/Fdt7 2tmCDIHiZHKRHT7r6Zt44dG82gPEbFa2u7aZBTFQS5XBTdaLgBwI4Xgv1ZD+P81td5m0/2X fIt4L3k0YgWqoBPeIPxu+b4i0U7RgR2wDXYz6Qqc/HpRLRFI5uKZ7HV0hnfNIMF/kHSFRBA OQO6QBjLNDlb2Z7xBdgBA== X-UI-Out-Filterresults: notjunk:1;V03:K0:NljzSbEPMDg=:Y1bn/m9l0w051qc9BRIS6S hGyBdNompSRgpM9Gt2eI21wx8tDTrANruUVyN2W2imYTxpOcyzv69m9bmA4vAMLL7hq2Gyz9l sqGZ+gIAnfAMU6C5BMUBPT7Pu0uFCF3O7KRjQeNal0PZ/OWszjEMrKwv1KglJfh7K/5UxXboU /r609tOB+qGCNRF1ZPnZ603thvD9FqwRVb5y5SucwMpc9BNdpP9HadQD8srrC/jgzyvh0dvnv 1909JxUmU67Xty27qRUDGX233Aap0nS/wtEGooHsnZad6Zkg/GjvmLhiouwywa50uWdfSHL6F GuEafTOhLJH3uIIQKGtRdK5LPkinF+2UzeCOxOrROT2VfaP+wW2LIWXmLRV0x70u9u7qu+P2p 6j1AXNZa3aF4oHuRfvPqOSJ4w4EU+QCA5imwhchh1VvBU4JY2Yw4XInIfIOd3/URS1+sOWhXN JfJKh/t9AXwBOCVMsuJak5HEZCJVAuQnZJ6UmB9ikNBsJeWVPHhB X-Spam-Status: No, score=-101.2 required=5.0 tests=BAYES_00, 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, 06 Apr 2021 14:20:46 -0000 On Apr 3 14:16, Ken Brown via Cygwin-developers wrote: > Some time ago I did a preliminary implementation of select for AF_UNIX > sockets on the topic/af_unix branch. I copied some things from the > fhandler_socket_wsock case without really understanding them. I'm taking a > second look now, and would like to clean this up. I'll start with just a > few questions, but there may be more to follow. > > 1. What's the purpose of 'except_on_write'? AFAICS, its only use is in > set_bits, to indicate that the readfds entry should be set in case of a > failed connect. But shouldn't that entry always be set if there's a failed > connect since a read won't block? Just looking this up in W. Richard Steven's book, and from what I can tell you're right. Basically, if a SO_ERROR type socket error occured, the socket is marked for writing and reading. except_on_write (the name is older and was originally used incorrectly) is only set if we really *are* connecting asynchronously at the time select is called. Only then the check for the connect state makes sense. Also, if the app is calling async connect and then select, the successful connection is indicated as ready for writing. So *typically*, this code is doing the right thing. However, *iff* the application actually calls select only checking ready for reading, then the socket error in case of a failing select would be lost. Not sure how useful this scenario is, but probably it wouldn't hurt to set the fd as ready for reading even if there's no check on ready for writing... > 2. In that same place in set_bits where UNIX_FD_SET (me->fd, readfds) is > called, shouldn't ready be incremented? Uh oh, yes. Thanks for catching! > 3. In fhandler_socket_wsock::select_write where except_on_write is set, > except_ready is also set. Why is that done there? It seems to me that this > is redundant, because the same setting of except_ready is done in > fhandler_socket_wsock::select_except. > > 4. Why do we set > > except_ready = saw_shutdown_write () || saw_shutdown_read () ? > > I can't find any documentation that says that a shutdown should be > considered an exceptional condition. On the other hand, POSIX does say, > "Other circumstances under which a socket may be considered to have an > exceptional condition pending are protocol-specific and > implementation-defined." So maybe there's some Cygwin-specific reason for > doing this? Nope, this is old (and wrong) cruft. Neither Steven's book nor the Linux man pages, nor testing on Linux imply that ready for exception is used to indicate anything other than out-of-band data. This should be fixed. Thanks, Corinna