From: Norton Allen <allen@huarp.harvard.edu>
To: Ken Brown <kbrown@cornell.edu>, cygwin <cygwin@cygwin.com>
Subject: Re: Unix Domain Socket Limitation?
Date: Sun, 6 Dec 2020 12:17:22 -0500 [thread overview]
Message-ID: <de5e7b33-405f-c62d-8800-674b121cd87e@huarp.harvard.edu> (raw)
In-Reply-To: <816668c9-4848-caa8-7fae-349be2cd5ab7@cornell.edu>
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.
next prev parent reply other threads:[~2020-12-06 17:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 21:47 Norton Allen
2020-11-25 22:27 ` Ken Brown
[not found] ` <4260ad1b-4ab2-fa36-fd0e-7c9644560114@huarp.harvard.edu>
2020-11-26 17:13 ` Ken Brown
2020-11-30 17:19 ` Norton Allen
2020-11-30 18:14 ` Ken Brown
2020-11-30 18:26 ` Norton Allen
2020-11-30 23:19 ` Ken Brown
2020-12-01 2:14 ` Norton Allen
2020-12-01 2:22 ` Norton Allen
2020-12-02 17:30 ` Norton Allen
2020-12-04 1:11 ` Ken Brown
2020-12-04 13:51 ` Norton Allen
2020-12-05 23:52 ` Ken Brown
2020-12-06 17:17 ` Norton Allen [this message]
2020-12-06 22:32 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=de5e7b33-405f-c62d-8800-674b121cd87e@huarp.harvard.edu \
--to=allen@huarp.harvard.edu \
--cc=cygwin@cygwin.com \
--cc=kbrown@cornell.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).