DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 22C0F3857C65
Subject: Re: Unix Domain Socket Limitation?
To: Ken Brown <kbrown@cornell.edu>, cygwin <cygwin@cygwin.com>
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>
 <a1f6e9af-7c0b-4d3f-4198-1c7bff4869dc@huarp.harvard.edu>
 <16165727-f614-1543-70bc-36457ddbf260@cornell.edu>
 <75d1315b-5a56-a2e5-310d-6ac33a3cf17c@huarp.harvard.edu>
 <f5373cd4-1d3e-500a-a967-1c558541e720@cornell.edu>
 <85c9c70f-c016-0f88-099e-5c772adbc648@huarp.harvard.edu>
 <fb523694-7775-1d7a-db55-27ccbd6d157c@huarp.harvard.edu>
 <1a0944b7-5924-31ab-7198-a5c311f39e06@huarp.harvard.edu>
 <1c1e875a-40a0-ff9e-a119-ba77203e43ea@cornell.edu>
 <a13ab85d-bee7-71e3-41d0-1a67422a859f@huarp.harvard.edu>
 <816668c9-4848-caa8-7fae-349be2cd5ab7@cornell.edu>
From: Norton Allen <allen@huarp.harvard.edu>
Message-ID: <de5e7b33-405f-c62d-8800-674b121cd87e@huarp.harvard.edu>
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-Language: en-US
Precedence: list
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Errors-To: cygwin-bounces@cygwin.com
Sender: "Cygwin" <cygwin-bounces@cygwin.com>
Content-Transfer-Encoding: 8bit

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.


--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple