From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from endymion.arp.harvard.edu (endymion.arp.harvard.edu [140.247.179.94]) by sourceware.org (Postfix) with ESMTPS id 22C0F3857C65 for ; Sun, 6 Dec 2020 17:17:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 22C0F3857C65 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=huarp.harvard.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=allen@huarp.harvard.edu Received: from [192.168.7.23] (pool-74-104-152-231.bstnma.fios.verizon.net [74.104.152.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by endymion.arp.harvard.edu (Postfix) with ESMTPSA id 8F5A36C096D; Sun, 6 Dec 2020 12:17:26 -0500 (EST) Subject: Re: Unix Domain Socket Limitation? To: Ken Brown , cygwin References: <71490665-31b0-f63c-74da-461a053fac21@huarp.harvard.edu> <55ea1649-1979-6238-75ab-69100c22e069@cornell.edu> <4260ad1b-4ab2-fa36-fd0e-7c9644560114@huarp.harvard.edu> <38a82f82-1ef9-768e-7d3e-15f63147e188@cornell.edu> <16165727-f614-1543-70bc-36457ddbf260@cornell.edu> <75d1315b-5a56-a2e5-310d-6ac33a3cf17c@huarp.harvard.edu> <85c9c70f-c016-0f88-099e-5c772adbc648@huarp.harvard.edu> <1a0944b7-5924-31ab-7198-a5c311f39e06@huarp.harvard.edu> <1c1e875a-40a0-ff9e-a119-ba77203e43ea@cornell.edu> <816668c9-4848-caa8-7fae-349be2cd5ab7@cornell.edu> From: Norton Allen Message-ID: Date: Sun, 6 Dec 2020 12:17:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <816668c9-4848-caa8-7fae-349be2cd5ab7@cornell.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 17:17:28 -0000 On 12/5/2020 6:52 PM, Ken Brown wrote: > On 12/4/2020 8:51 AM, Norton Allen wrote: >> On 12/3/2020 8:11 PM, Ken Brown wrote: >>> >>> I'm traveling at the moment and unable to do any testing, but I >>> wonder if you're bumping into an issue that was just discussed on >>> the cygwin-developers list: >>> >>> https://cygwin.com/pipermail/cygwin-developers/2020-December/012015.html >>> >>> >>> A different workaround is described there. >>> >>> If it's the same issue, then I don't think it will happen with the >>> new AF_UNIX implementation.  More in a few days. >>> >> It does seem related. >> >> A work around that is working for me is to do a blocking connect() >> and switch to non-blocking when that completes. In my application, >> the connect() generally occurs once at the beginning of a run, so >> blocking for a few milliseconds does not impact responsiveness. > > For the record, I can confirm that (a) the problem occurs with the > current AF_UNIX implementation and (b) it does not occur with the new > implementation (on the topic/af_unix branch).  With both client1 and > client2, I see "connect() apparently succeeded immediately" using the > new implementation. > > The new implementation is not yet ready for prime time, but with any > luck it might be ready within a few months. > That sounds great, and exactly like the behavior under Linux. I'd certainly be happy to test the new implementation as it gets closer, and also happy to expand or improve the test apps to cover a wider range of functionality and/or usability (e.g. run both client and server via a fork.) Feel free to let me know what would be particularly useful.