From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2125.outbound.protection.outlook.com [40.107.237.125]) by sourceware.org (Postfix) with ESMTPS id 6E4753858D28 for ; Mon, 19 Sep 2022 21:25:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6E4753858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cornell.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cornell.edu ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NUzUcJRtVNYnOs48ODvJQUAPBRtj5CytHCyhhFcyQXR+yWa49wD8dHCZlxUAUNbFoCGjoi/0wWK4cpxzyjUQPPFM0WR/wT+Fj8TBQ1GTwU1fty5k+avKuQ3kwAXR/bqOy2YGG6JbsI8j4W8wEej9aX4pQwmd9c1ncffqZSb+bccyFS8EDHVrKPYlye7AmoKQH+zEFmBxdZ0hetSRnqnneGF+BZBlOhHHmxQvnHvV0A7DLLYJzyovPs5KidpF/GGEEOk01iZpqLEY+wZcjKT2JFZ4h4fqhZCN3P8nxS0TkAmau0gKS71P/QLghq/PzertqBROPVhnDxOq0ynecdXEWw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lLjd65Q+Vwf++e2PwvMKFJqIpUXT+ehGxl+YmrYxeSs=; b=clA4NNtq7aohlqVihmivaYQWgJ8zqYBwQJPNCRnvPU4/UwrTl97g9aTwELz2fh5oSf0964j4RW8tjeKdDr9/oIWbI2GpKwCRLE7C2j7mJqncWC0bCckA1uY2bqjqJAXA+D7irRUHG/YP0h9/SmXEm53J7JUTGV/UZo6CvTJhbR2eN20Jn4skRG1ITul4oSAPyvw05LSqW4ZZt1YtO9WDqovETqw2S7ETtCIwtpYDUYD9NiSYovZNvHalNVl1IAafPCZQ7BtZJLzEGTr5Qk6+6/MgxF31mwiKJrivNIBLexaqrumqjhQFz88E53eIFXnR5NPb4ba10ju9IcurTdxqZQ== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lLjd65Q+Vwf++e2PwvMKFJqIpUXT+ehGxl+YmrYxeSs=; b=I6CuhC7Ps+0lu18snudkpHeMOZi2jh+7VT2nlj5raI3OPvYNV6sxV5tk/nVdVhwmk6vqD6SutermyKaZ0U9ZRr2Lhqi5y7BMCAr+T9Gf+So2eNn9qn7U2C9kysRoJADZaeOVB/5gULk1vVcrFq4osKFjS+NvM4SbCJrZACHp2hs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cornell.edu; Received: from SA0PR04MB7322.namprd04.prod.outlook.com (2603:10b6:806:e2::7) by DM6PR04MB4443.namprd04.prod.outlook.com (2603:10b6:5:a5::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.21; Mon, 19 Sep 2022 21:25:32 +0000 Received: from SA0PR04MB7322.namprd04.prod.outlook.com ([fe80::91f5:ea9:176e:ad14]) by SA0PR04MB7322.namprd04.prod.outlook.com ([fe80::91f5:ea9:176e:ad14%7]) with mapi id 15.20.5632.021; Mon, 19 Sep 2022 21:25:32 +0000 Message-ID: Date: Mon, 19 Sep 2022 17:25:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: FIFO issues Content-Language: en-US To: cygwin@cygwin.com References: <140f644c-4c30-9381-3917-d9f18a0de29d@cornell.edu> <5d69ee45-a393-bd54-2d7b-2d59117089f6@huarp.harvard.edu> <6a85ccdf-8e35-241b-ea63-bf9b5f4c85b8@huarp.harvard.edu> From: Ken Brown In-Reply-To: <6a85ccdf-8e35-241b-ea63-bf9b5f4c85b8@huarp.harvard.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: BL1PR13CA0016.namprd13.prod.outlook.com (2603:10b6:208:256::21) To SA0PR04MB7322.namprd04.prod.outlook.com (2603:10b6:806:e2::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA0PR04MB7322:EE_|DM6PR04MB4443:EE_ X-MS-Office365-Filtering-Correlation-Id: 9cc4bb95-1d15-416a-bf77-08da9a857bc7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PnQkw+V6TtQdi/cFpoopWI0hxy34Rw80Fd+R3psaowRX7DlYxLSPtj+Rm/KePi+Z4vCcG2KDwkxJyJGLB7IecdTabEOevScgcrtdazBF0CBIcRVjJy/VbkfsCcOFEARz54qkgTqJZyLGCy9KmzPQXTsaa+I2Yv0ctazQe8Hg6Do/CoN25uBOsGArpS67USiX+OwdroBTx7eBwg96LMXVwNXoPcbiMs8e5DORoJPPqNidOVwLPo6ySUo+lH0WggOQk/JOy81K27wKsXdrVhIn8NQIF/USgVsASwO3p6TjDIowlK/vHIrU5VuT8erIQOubmXT4a/al39gOo650xTcT7lhpGtWKSAIROyMy6dBNFgceOt/tznZPI/znljWqDdo/LW7+0xb6RUal/LcWKa/tdOepUVZ/EzVQRhhElBhY3sOjJ3V5129AkAnJENGr+L0kMwVKoPaJyuAGtf8yx0fy2nmaLq1+Gh8GHpVZzNCZ1KqlrQVeEEEqJ691kR0qpTU3NBe+eKH2yH52JJVZ7r454BQiBQNU1+JPjntQ2HznqdaSt67cTs6TNs3LHWWqO8oTQc+cBnbZ6CTo2MLUR6xNaFOOuNcuYkQDad7lDTKL2zgkYlRNHIcSZdGi2b7nwTPP3eZAq1ZOZKt8/yfc+kHiqAgyTz4j6cCU92KdpSmDua3vWQxN3zbkAi4P2rnOT9+QrHS33F/L529hxLQ5NThL9TtDdvoW3ToMWbrZHZ4t/KBKZ+/jJmz4J7cua9j2JPV9w+pqrN1e75ySqwKdfHbqd0OAfHruQtmQpYyATWmb62dnm2MNM32yVePwbfj9xzTPYTCZgQIqeqE59hy+1TqQAQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA0PR04MB7322.namprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(346002)(376002)(136003)(366004)(396003)(39860400002)(451199015)(2616005)(2906002)(966005)(3480700007)(66946007)(53546011)(41300700001)(6506007)(31696002)(6666004)(8676002)(75432002)(66574015)(83380400001)(6916009)(66476007)(66556008)(786003)(316002)(6486002)(36756003)(5660300002)(7116003)(186003)(8936002)(478600001)(41320700001)(86362001)(6512007)(38100700002)(31686004)(43740500002)(45980500001);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c082RngrRzF3N3JzMU5Bc3hFM3E1NW1WK3IwVWlIa3lLUWQwdW9MQng4Q1p1?= =?utf-8?B?MnFlVmRkTWMreEM0aGp3SE1mNVppRmJVNzdOMWU1citCY3B0cm1HbElMV01j?= =?utf-8?B?Ky9ZSXRBTStCUFBBdFJmTld1MlZXTWFINWxSSFFjZCszT0U1SFlTQTZuSlJL?= =?utf-8?B?MTFIdE0rS1F1WUhCblBLV0NGMGpXOEM3QXAyYlYwTkdicUUyeUtZWkllM3Fx?= =?utf-8?B?aWY3NzZQdUw0Z0pUK3FEZ1EyYVlPOG13czRIb0tOTno0Q1krUk9PMVJWL3JT?= =?utf-8?B?clNpYVhtR3gzQVM0UUlKazhXR3ZqSW1FUGg3bFdPRWFRNGtKaU9wZDB2TGVt?= =?utf-8?B?ZW52cUp6ZG9uZkFyQkx6QTBYcDJCMk52UHkyWklyVitRdmFtU1krdXVZUkUz?= =?utf-8?B?b0tONGJFSGpneDhQcGNyRmNKeHNlL3dVTWZHcWlabjRiOWNBbWV2M0ZyV2Zh?= =?utf-8?B?UVBqeWZuQ01sTzl6eWdMYzMzTWxHUTZzYTlJbjRPUXk5OVdia1RMMmhIa3VT?= =?utf-8?B?QUhyckVuN01KWm9CY3Z2OWhKK0txSVc0RXgreEc4RW5hajMzNzVwa3BXdmMr?= =?utf-8?B?Z0xkc3Jtd0VFQVpwMlpNbDhvcTFoTzE0eitpZGVoSG5QclhxUUVGbkJjWnRh?= =?utf-8?B?WW9HUGMybExWZ1ZQTHQrdm5wVjRLcC9USjBkVlpxUmY1eEcxQlMxWldOL3g4?= =?utf-8?B?UVI4aGJDd1RlZVJ4OUZZWTRKZlA0UmZ1MTNCMFVjQmFJT01LWmlQTldoMmRM?= =?utf-8?B?ckZDaURKdUNlb2FBODEvcElnTmJ2dm53WTUzc2d1aVBzbHU1KzJLNHhiWFhh?= =?utf-8?B?SkN1Y3lrTDlwaGswTUtiQmUwdVNwZWJ6RVU5Q0dIMVV1ekVZek9xTmx4cWt1?= =?utf-8?B?ejlPaG45ZGNzQkNmWTEwTWVpZm1JN2I4WEJGS1kvQzA2YTUybmdKenR0dmRC?= =?utf-8?B?WWt5OFJLT3h6UG5wSlB6SFNTWjQwZGU1ZTdCQVpVa0NhQysraWRGMW5MUysy?= =?utf-8?B?ZWJIQ1Urc3ovNWRDZ3p1a29WV1BsdHZId0FZcUJFYytKeGdzMC9lNnZSRFhK?= =?utf-8?B?YXpEVm4wZy9TeUtPcDNZaEU2YkszRFN2NFQxY0FuK1ZCTXdmS1JPKzdjeHFF?= =?utf-8?B?SVYvejZMZ2xNb2xKK1JQMllYMTRFbUdHZjNHc01GR0tKRExWUjdUTGN2bmdr?= =?utf-8?B?ODJDcUlVK3d6UWNzQlZDR3AwR01pNGdPUjFOajZHMGFqcm1maCtSNlBlRStv?= =?utf-8?B?UW1KNGZZUHJHK0tVd2t4UllFbWQyL3lONW9GK205WnNCUndBbnl0bk0va0dt?= =?utf-8?B?eDJhMmV1MWY1U0swMzQvWnZFWVduYk9BRXg2WWs1ZjQ3WmRoYktldXNYbGxj?= =?utf-8?B?VkdxUlMvNG5wa3puN2xOVlJhUGdEUFdPNER0M0g0dXhvVUhzbm05OWREVUdJ?= =?utf-8?B?RzlMQ29NZlVsNWhBeGJIUnJjZFBiaGhEZ2lUTHlKRFdOK01RNU1WU1ZsVXNp?= =?utf-8?B?R3I3WjEvUStYczdXWkJGVkd5L0hPNU80c2lMdVB0T2hXSnhtWnhNYXVxK3JG?= =?utf-8?B?ZjU5K2RWeFhBN05tUW1YUUdQZDhka0xYOXNKME5CMkRrTkZKWnpVTmkyYm14?= =?utf-8?B?bTY3cnN1UWlleHdQMDJTUG5yaDE3N2JhdnlGdG9OUFBlRGoxV01MVXBnaTgz?= =?utf-8?B?eXQvenUzTW82TmFaK0NmMG5rYVNSeVRZWmc1bE5talhyYjZYR3BwR0ZDV1ls?= =?utf-8?B?UlRRZzIzZ0QycityaFFpQVZSbVZTaXYyNG5hMm0yNm1yS2FtODNDM2RScTBV?= =?utf-8?B?OVpQbHVIdmVRSWhMa1FUYlFUaU1Gdk5XMUpBTmRhcjlncWpOam02Slp2cUZK?= =?utf-8?B?WjJMa0F3YlpCY3FzM2Y1cUcyWXZsQTFTVXZ6cSs3WWk3aFBwMjFvZzkvMUpx?= =?utf-8?B?aC95UXpwdjlON25uUUdXWEpHQXRyK29sTWY0K2hjQVdlSW1Ja25zcjdyY2ll?= =?utf-8?B?K0RadUR6NnhCN0g2K3hVRk5EZlBya0dNR1JnWFpDNnorMmdPYmgzOWVBSW01?= =?utf-8?B?R0NsMXRvNmxQQlRrZHlhYmIra0ZLSHBzU1k3Wld4WkhSWE5ST2xVOWNKVHB4?= =?utf-8?B?aDVreU5CcXRSTXEzU0JiekpWU2U3SUdZZURadGVXbUNvU1d6ZjJVK01RY3Np?= =?utf-8?Q?PPO7TQCjJ+IKz4h3un5Vqr1Y8TrGuicwPeerft6/XIL3?= X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 9cc4bb95-1d15-416a-bf77-08da9a857bc7 X-MS-Exchange-CrossTenant-AuthSource: SA0PR04MB7322.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2022 21:25:32.5611 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EPz2hq6dSJ+QUktFXEVzoKgpUL/tH+b6gWhXBKpdAA7XEuqnot+SBn5ui7orBoXLrFwWS81gehQlQhlEEnvYIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR04MB4443 X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/19/2022 3:53 PM, Norton Allen wrote: > On 9/19/2022 3:50 PM, Norton Allen wrote: >> >> On 9/19/2022 3:15 PM, Ken Brown wrote: >>> On 9/18/2022 5:45 PM, Enrico Forestieri wrote: >>>> Hi, >>>> >>>> I think I am experiencing a problem with fifos on cygwin. The attached >>>> C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting >>>> to receive inputs from /tmp/pipe.in and replying to /tmp/pipe.out. >>>> >>>> Compiling this source on linux and launching it produces on the terminal >>>> >>>> 1) Opening pipes >>>> >>>> and then the program waits for someone to write to /tmp/pipe.in. >>>> Opening another terminal and launching the fifotest.sh script (also >>>> attached) produces on the first terminal >>>> >>>> 1) Closing pipes >>>> 2) Opening pipes >>>> >>>> and the program continues waiting for another input, while the other >>>> terminal shows "You sent: foo" >>>> >>>> Instead, on cygwin, after launching the program one gets: >>>> >>>> 1) Opening pipes >>>> 1) Closing pipes >>>> 2) Opening pipes >>>> 2) Closing pipes >>>> 3) Opening pipes >>>> 3) Closing pipes >>>> 4) Opening pipes >>>> .... >>>> .... >>>> >>>> meaning that the pipes are continually closed and reopened even if >>>> nobody is writing to /tmp/pipe.in. >>>> >>>> Seemingly, the problem is the return value of read() on line 55. >>>> As O_NONBLOCK is set, until no data is available for reading, >>>> read() shouldn't block but should return -1 and set errno to EAGAIN. >>>> After a client that opened the pipe for writing, closes it >>>> (and no other client is using the pipe), read() should return 0 and >>>> only at this point the pipes have to be closed and reopened. >>>> >>>> However, on cygwin, read() returns 0 also when nobody is writing to the >>>> input pipe causing the above ping pong. As already said, it works as it >>>> should on linux. >>> >>> I see what's happening, but I don't see why it's a bug, and I don't >>> understand why the Linux behavior is different. >>> >>> On Cygwin, the call to 'select' in line 44 returns immediately with nsel == >>> 1. This seems correct to me, since the man page for 'select' says, "A file >>> descriptor is ready for reading if a read operation will not block; in >>> particular, a file descriptor is also ready on end-of-file."  In the present >>> case a read operation will not block for two reasons: first, O_NONBLOCK has >>> been set; second, we're at EOF because no process has opened /tmp/pipe.in for >>> writing.  Given that we're at EOF, the return value of 0 for the subsequent >>> 'read' is also correct. >>> >>> On Linux, 'select' does not return immediately but instead waits for someone >>> to write to the FIFO. >>> >>> Can someone explain why Linux is right and Cygwin is wrong here? I must be >>> missing something obvious. >>> >>> Ken >> >> This is how I'm reading this, but I have not actually looked at or tried the >> posted code yet: >> >> We use select() specifically when we are using non-blocking I/O. All the >> blocking happens in select() so we can track multiple sockets. If select() >> returns when there is no data available, it's not really doing its job, i.e. >> waiting for data. There are of course particular cases where something else >> (opening, closing) causes select() to return, which is normal and expected, >> but just because the reader is non-blocking is not a good reason for select() >> to return. >> > I should also mention that I use cygwin pipes extensively and have not > encountered this behavior, so maybe I am doing things differently. You're probably not calling select to check for read ready on non-blocking FIFOs that have no writers. In the meantime, I just checked what POSIX says about the meaning of "read ready" in select, and it's more clear than the Linux man page (quoted above) about the non-blocking aspect: "A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully. (The function might return data, an end-of-file indication, or an error other than one indicating that it is blocked, and in each of these cases the descriptor shall be considered ready for reading.)" So I think the Linux man page was just imprecise about this, and select should not indicate read ready just because O_NONBLOCK was set. But what about the EOF aspect? In the OP's test case, the FIFO was opened for reading and there were no writers, so again it seems that select should return read ready and a subsequent read should return 0. But Linux disagrees. I did an internet search on this issue and found the following, which describes the situation we're discussing: https://stackoverflow.com/questions/14594508/fifo-pipe-is-always-readable-in-select According to that post, select on Linux will wait for a writer the first time it's called to check read readiness for a FIFO opened for reading with O_NONBLOCK set. But if the writer then closes the FIFO, subsequent calls to select will always find the FIFO read ready (and read will return 0). This behavior is not documented, as far as I can tell, and in fact it contradicts the existing documentation (both POSIX and Linux). So I don't think someone trying to write a portable program should rely on it. Ken