public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: cygwin <cygwin@cygwin.com>
Subject: Re: Unix Domain Socket Limitation?
Date: Mon, 30 Nov 2020 13:14:52 -0500	[thread overview]
Message-ID: <16165727-f614-1543-70bc-36457ddbf260@cornell.edu> (raw)
In-Reply-To: <a1f6e9af-7c0b-4d3f-4198-1c7bff4869dc@huarp.harvard.edu>

On 11/30/2020 12:19 PM, Norton Allen wrote:
> On 11/26/2020 12:13 PM, Ken Brown wrote:
>> [Adding the Cygwin list back to the Cc.]
>>
>> On 11/26/2020 11:27 AM, Norton Allen wrote:
>>> On 11/25/2020 5:27 PM, Ken Brown via Cygwin wrote:
>>>> On 11/25/2020 4:47 PM, Norton Allen wrote:
>>>>> In my recent tests, it appears as though it is not possible to successfully 
>>>>> connect via two Unix Domain sockets from one client application to one 
>>>>> server application.
>>>>>
>>>>> Specifically, if I create a server which listens on a Unix Domain socket 
>>>>> and a client, which attempts to connect() twice, both seem to lock up. This 
>>>>> is not the behavior under Linux.
>>>>>
>>>>> I will be happy to work up a minimal example if it is helpful in tracking 
>>>>> this down. I wanted to start by asking whether this is a known limitation 
>>>>> and/or if there is something about the Cygwin implementation that makes 
>>>>> this sort of thing very difficult.
>>>>
>>>> A minimal example would be extremely helpful.
>>>>
>>>> Corinna can answer questions about limitations in the current 
>>>> implementation. But there is a new implementation under development. It's in 
>>>> the topic/af_unix branch of the Cygwin git repository if you're interested 
>>>> in looking at it.
>>>>
>>>> Corinna began working on this a couple years ago, and I've recently been 
>>>> trying to finish it.  I've made quite a bit of progress, but there's still 
>>>> more to do and undoubtedly many bugs. So any test cases you have would be 
>>>> very useful. 
>>>
>>> Thanks Ken,
>>>
>>> As it happens, attempting to produce a minimal example suggests my problem 
>>> may be somewhere else. I think I've worked in most of the features of my 
>>> application one by one but have not yet revealed a failure.
>>
>> OK.  But if you ever do have occasion to write small test programs involving 
>> AF_UNIX sockets, please send them on.  The new AF_UNIX code needs as much 
>> testing as it can get.
>>
> I have finally put together a start of a minimal example, although it seems to 
> require a certain level of complexity before tripping on the bug. At the moment, 
> I do not believe the issue is related to having multiple sockets between the 
> client and server. I am thinking it is some sort of race condition related to 
> non-blocking sockets, since I have only observed it when both the client and 
> server are using non-blocking sockets.
> 
> I have yet to plunge into cygwin.dll, but I think I have reached that point.
> 
> Here is the code: https://github.com/nthallen/cygwin_unix
> 
> Since I have only exercised this on my machine, I would be very interested to 
> know if it is reproducible on anyone else's.

I can reproduce the hang, and it happens if I use the new AF_UNIX code also. 
But what I'm seeing (at least with the new code) isn't exactly what you describe.

When the server's first select call returns, accept succeeds.  The server then 
calls select a second time, and that call doesn't return.  I haven't checked yet 
to see what's going on in the client, and I may not get to that for a while.

Ken

  reply	other threads:[~2020-11-30 18:14 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 [this message]
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
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=16165727-f614-1543-70bc-36457ddbf260@cornell.edu \
    --to=kbrown@cornell.edu \
    --cc=cygwin@cygwin.com \
    /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).