From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on20717.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e8b::717]) by sourceware.org (Postfix) with ESMTPS id 8CA6E3857832 for ; Sat, 5 Dec 2020 23:52:51 +0000 (GMT) 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 Received: from MN2PR04MB6176.namprd04.prod.outlook.com (2603:10b6:208:e3::13) by MN2PR04MB6208.namprd04.prod.outlook.com (2603:10b6:208:e3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Sat, 5 Dec 2020 23:52:49 +0000 Received: from MN2PR04MB6176.namprd04.prod.outlook.com ([fe80::113e:c874:1207:eca8]) by MN2PR04MB6176.namprd04.prod.outlook.com ([fe80::113e:c874:1207:eca8%6]) with mapi id 15.20.3632.021; Sat, 5 Dec 2020 23:52:49 +0000 Subject: Re: Unix Domain Socket Limitation? To: Norton Allen , 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> From: Ken Brown 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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: 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@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: Sat, 05 Dec 2020 23:52:54 -0000 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