X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08E7A384400F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1607212376;
	bh=jxm6NqA8CPBmx6FGhMFYx8pMiB2otflxv12Sm3dgPWA=;
	h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=RWtpvye7gdzZ9NKOROlLDiLgL4A238s5/PsIz7VOtQnyHkaSbWezUYAO/5LuTtBWk
	 tZ7UvofjJSr8XSu+BKR7RxRV/mWA1rbTZCXcsq8kV8m2El3s+kHTqqyIskAHVViPt2
	 U2Ari/Zy8egtY/x+Bg8+61UJySPse8C7aQIPT7G4=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8CA6E3857832
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=kpLmmifxYFQqXxCkl5SS5pdrXZNFJDuABSYgEbfJ61AOKMzINxHAiKMqB96WF+gLozt+D9zcR5IhTKZpf/jPRAhuWfDfKAnMfUo1Doi1cHtN7CX+R4vXCnnlSGD7F54Ye8u5TsG7u7OhibN7aLb5gOAUmmRSJ9amA48HmMP6HfcwZGaCIgJB2mAOJ7epBHw9w3ZVCxVUFGLKd3xnZZCikfzWub4GfMXPUyRoExR1W2SUT0Wb8wL1UA5BW2Xcl38iA5SGtewDgbjh0Myc5Jezguk5E/nGNz6ZZclXnRrRPVTl1zVBTaZYNvFB8SKAnbMOhSrzNK0pwNKHSeCis92U4Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=wAbx7sb2dk36b0hmyeTWGWMAeiYUR+wUATgg/v07aAU=;
 b=kfgMdwbS6KeK8lWIVPquxdu7XrXYfmyNhwA5V3Tlh9d+lD3IpGtvsUs5LTcvY3hVNz3qpjynYgR3yV6y3K4b6jm6tGhfLkw5V9PRsxPkbtBr7RqUzj4J682enC6AxEbB03H4902JN/4lUe+Iyc1STiquBonGHWu4vLTsO16Mmk51uE7nfRrDu7bDTWOciOXVObllePTcC9EtSV8I6OZnNS1VjOS3rVbnVr9VjrLNzIUhCrJ83TYhjs51bc3x1I7cHq6zsHrq7/FbFfH/ouE1gg6TFTY+sUtbM9sje60pxo8Q4ujcOjMvJE8VUQRXV5mhwouPxMlkp2eLhqTAUuV6CQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=cornell.edu; dmarc=pass action=none header.from=cornell.edu;
 dkim=pass header.d=cornell.edu; arc=none
Subject: Re: Unix Domain Socket Limitation?
To: Norton Allen <allen AT huarp DOT harvard DOT edu>, cygwin <cygwin AT cygwin DOT com>
References: <71490665-31b0-f63c-74da-461a053fac21 AT huarp DOT harvard DOT edu>
 <55ea1649-1979-6238-75ab-69100c22e069 AT cornell DOT edu>
 <4260ad1b-4ab2-fa36-fd0e-7c9644560114 AT huarp DOT harvard DOT edu>
 <38a82f82-1ef9-768e-7d3e-15f63147e188 AT cornell DOT edu>
 <a1f6e9af-7c0b-4d3f-4198-1c7bff4869dc AT huarp DOT harvard DOT edu>
 <16165727-f614-1543-70bc-36457ddbf260 AT cornell DOT edu>
 <75d1315b-5a56-a2e5-310d-6ac33a3cf17c AT huarp DOT harvard DOT edu>
 <f5373cd4-1d3e-500a-a967-1c558541e720 AT cornell DOT edu>
 <85c9c70f-c016-0f88-099e-5c772adbc648 AT huarp DOT harvard DOT edu>
 <fb523694-7775-1d7a-db55-27ccbd6d157c AT huarp DOT harvard DOT edu>
 <1a0944b7-5924-31ab-7198-a5c311f39e06 AT huarp DOT harvard DOT edu>
 <1c1e875a-40a0-ff9e-a119-ba77203e43ea AT cornell DOT edu>
 <a13ab85d-bee7-71e3-41d0-1a67422a859f AT huarp DOT harvard DOT edu>
Message-ID: <816668c9-4848-caa8-7fae-349be2cd5ab7@cornell.edu>
Date: Sat, 5 Dec 2020 18:52:47 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
In-Reply-To: <a13ab85d-bee7-71e3-41d0-1a67422a859f@huarp.harvard.edu>
Content-Language: en-US
X-Originating-IP: [65.112.130.200]
X-ClientProxiedBy: BN6PR10CA0008.namprd10.prod.outlook.com
 (2603:10b6:405:1::18) To MN2PR04MB6176.namprd04.prod.outlook.com
 (2603:10b6:208:e3::13)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.13.22.3] (65.112.130.200) by
 BN6PR10CA0008.namprd10.prod.outlook.com (2603:10b6:405:1::18) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3632.17 via Frontend Transport; Sat, 5 Dec 2020 23:52:48 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 3fb7ea23-c1e5-4e0a-7821-08d89978df48
X-MS-TrafficTypeDiagnostic: MN2PR04MB6208:
X-Microsoft-Antispam-PRVS: <MN2PR04MB62089355394BF3F8F74260AED8F00 AT MN2PR04MB6208 DOT namprd04 DOT prod DOT outlook DOT com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: XEtx2ktf7znztKEJo5VX3Gy3AqgzxoaGh2ouS3a8sR6cqP9NSHCl9QL9Rn5IDPI8IZs0hilEQyxtlTRysUjhpwDu6bWqizSQeypXzBE2amReartc8OcYj8ELFUKwpC8D75pTSI5nBwjRpS1XRnPNjU9MrxuUAI6B2TS6XcsI+j09EZP2Oi93NjUSZOlUgyIA1/pjwJ7ey9SFt6yHsqHjNJIxeX4X/fxb+EQMT7LlBKTyBROlOHtv5DdXamVdp4Kvz15qjkHDn4l/0Jaji+APhunqaVwFIXqKNWv2QUI1q8aiR/jsMF0nhZQIIafoh9OB+87VJpGAiMYsyzEFoKUFV1ZtbmE4GUp4ziJj6PGTOLWT0AMH9IKQs63DnX03J/leJFu3ObYOhRfQLLD7q2wi3fI7adFpKKnOx/C4+PC6aIgCyeowpW09zVgIrfZVe3KIdA3UfUBb3c+CWSrf+9bjIbQCdaat0ZfONmoY4wFYvpm5g/MKtm/sc6AsB2hi90UZ
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:MN2PR04MB6176.namprd04.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(186003)(53546011)(16576012)(2616005)(66476007)(6486002)(31686004)(83380400001)(26005)(110136005)(786003)(52116002)(316002)(478600001)(36756003)(86362001)(5660300002)(75432002)(66556008)(16526019)(3480700007)(966005)(66946007)(8676002)(956004)(31696002)(8936002)(2906002)(43740500002)(45980500001);
 DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData: =?Windows-1252?Q?QZ4dsV0CBikeufjnYJxPJ/b3Hp/ijC6gNZxJkGkOW3H40ztC9E4uBgOc?=
 =?Windows-1252?Q?F/fVKuRh3EYsaPw7g3K3cM8N1RcyeiivDPnimCqpgMNB9lPi47o1fK3Z?=
 =?Windows-1252?Q?+URUS7g07vAD1Uk/yi4h6FgfUloOEucuwWGVwsm8LOdI80oNkaZADpxs?=
 =?Windows-1252?Q?Bon/OqUqEfSQisFzojqdRA+d1DoEauaoNaSKFCycNwiFRpxdC619L1YZ?=
 =?Windows-1252?Q?hum+yJXrm0M7YU5JD/PxQPzLNzbrcpkgBRowpDta2m9EcG8pY1+zEpUH?=
 =?Windows-1252?Q?ZDYSAS18gPVGo0oNk06RHJzM3740woAX2hK653Wnb1GP2Bkl5Wm/PFya?=
 =?Windows-1252?Q?+QiRLso2WTPlig3H034+xD06a58AaeOuKLnY+/1iwtzuZAiSBY3D/f+7?=
 =?Windows-1252?Q?VeypY7lctepTeNjdJJZJ+bwnHoBwGJmLaPTTslZcqK8ONieI8L7pePUH?=
 =?Windows-1252?Q?0i89rLXLlmVl1Y17V/OorU1QyCcy2DhaFPBt+T5EF4rBrB8/uRJae/YN?=
 =?Windows-1252?Q?pPyITXf0koDQSgegAjgpM7Lrb4Tboq6mSE3hw+AKl2zfYhbp333iz9bG?=
 =?Windows-1252?Q?Br0iB1WikpcfjH9vR0q4dCtA4e5VLSjUDfjfha+iXlzZZnF8rNc0q5lA?=
 =?Windows-1252?Q?HDWCEmO7B2CRYtMqEpv/HPFCWoE1T62+ccVF/6/WP7T4TP3xqyFI9l4W?=
 =?Windows-1252?Q?GPz5u2cNTULKfwoh7tLVhOZiGnlOjhDcPCRTn6gPmDtNnPuU5JKIyuYg?=
 =?Windows-1252?Q?thJYl3Td+CfOd/M8/rD5EQCN4m1JoCGlB3vwXZuCMaqa0dSLgmYSEVxo?=
 =?Windows-1252?Q?karJFQTbqoV/Ha0U9wnTmXm4VLCSESF/jHb3ruKJRU2/vit7+PWqWEeX?=
 =?Windows-1252?Q?Z9IYrZJSfcCEnk90Rmvop7slfRP+q7P3uiShuGlXAL17jCWNB3IWe/jk?=
 =?Windows-1252?Q?QEx7uj55iwqjD9kSXf0XH5kHEio+bjO70qk8ypBLBsHEOzBuOHsikbWb?=
 =?Windows-1252?Q?YqUF4yr6seOI/5mkxq7rrb+/skBT60CviU7xQxP2zXNJ14tPGl37tsxr?=
 =?Windows-1252?Q?JL/ck0i4crbBBKiD?=
X-OriginatorOrg: cornell.edu
X-MS-Exchange-CrossTenant-AuthSource: MN2PR04MB6176.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2020 23:52:49.3089 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1
X-MS-Exchange-CrossTenant-Network-Message-Id: 3fb7ea23-c1e5-4e0a-7821-08d89978df48
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XU1BCMgrxr9IOUc09E6Ti/Y5kR6Gtvq1IKQNMUg5KumvZOmxq7dMaFHonkNNWEfKs22QsuylAc9gaZRPysLMsw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR04MB6208
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00, DKIM_INVALID,
 DKIM_SIGNED, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, MSGID_FROM_MTA_HEADER,
 NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=no 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 AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Ken Brown via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Ken Brown <kbrown AT cornell DOT edu>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 0B5NrLu3019435

On 12/4/2020 8:51 AM, Norton Allen wrote:
> On 12/3/2020 8:11 PM, Ken Brown wrote:
>> On 12/2/2020 12:30 PM, Norton Allen wrote:
>>> On 11/30/2020 9:22 PM, Norton Allen wrote:
>>>> Yeah, so now the example no longer blocks for me. Unfortunately these bugs 
>>>> are not present in my application, so I will need to keep working on this.
>>>>
>>>
>>> After paring the main application down and back up, I finally narrowed in on 
>>> the condition that was causing this blocking behavior. The issue arises when 
>>> a client connect()s twice to the same server with non-blocking unix-domain 
>>> sockets before calling select().
>>>
>>> There are a few pieces to this. With the client configured to connect() just 
>>> once, I can see that the server's select() returns as soon as the client 
>>> calls connect(), but then the server's accept() blocks until the client calls 
>>> select(). That is not proper non-blocking behavior, but it appears that the 
>>> implementation under Cygwin does require that client and server both be 
>>> communicating synchronously to accomplish the connect() operation.
>>>
>>> I tried running this under Ubuntu 16.04 and found that connect() succeeded 
>>> immediately, so no subsequent select() is required, and there does not appear 
>>> to be a possibility for this collision. That proves to hold true even if the 
>>> server is not waiting in select() to process the connect() with accept().
>>>
>>> A workaround for this issue may be to keep the socket blocking until after 
>>> connect().
>>>
>>> I have pushed the new minimal example program,  'rapid_connects' to 
>>> https://github.com/nthallen/cygwin_unix
>>>
>>> The server is run like before as:
>>>
>>>     $ ./rapid_connects server
>>>
>>> The client can be run in two different modes. To connect with just one socket:
>>>
>>>     $ ./rapid_connects client1
>>>
>>> To connect with two:
>>>
>>>     $ ./rapid_connects client2
>>>
>>> My immediate strategy will be to develop a workaround for my project. Having 
>>> spent a day inside cygwin1.dll, I can see that I have a steep learning curve 
>>> to make much of a contribution there.
>>
>> 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.

Ken
--
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