From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id C896E3858D29 for ; Mon, 15 Feb 2021 09:23:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C896E3858D29 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-190-UkyE_UhFOWCFhOh1gD349Q-1; Mon, 15 Feb 2021 04:23:54 -0500 X-MC-Unique: UkyE_UhFOWCFhOh1gD349Q-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 86918107ACE4; Mon, 15 Feb 2021 09:23:53 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-131.ams2.redhat.com [10.36.113.131]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 857B8710DC; Mon, 15 Feb 2021 09:23:52 +0000 (UTC) From: Florian Weimer To: Tobias Bading via Libc-help Cc: Godmar Back , Tobias Bading Subject: Re: (stat(...) == -1 || faccessat(...) == -1) && errno == EINTR ?!?? References: <000830b6-1cf0-6349-5667-a5af6894ac1b@web.de> Date: Mon, 15 Feb 2021 10:24:16 +0100 In-Reply-To: (Tobias Bading via Libc-help's message of "Mon, 15 Feb 2021 10:15:24 +0100") Message-ID: <87czx1fzun.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, PLING_QUERY, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 09:23:58 -0000 * Tobias Bading via Libc-help: > English isn't my first language, so I must be reading this wrong or > interpreting it in the wrong context. If a POSIX implementation was > allowed to add EINTR to the list of possible error codes returned by a > function defined in the standard, what kind of standard would that be? > How about an implementation of malloc() which returns NULL and sets > errno to EINTR when a signal is raised while the calling thread was > asleep because it was waiting for a disk read from swapspace? XD Returning EINTR in stat would allow relatively straightforward implementation of a timeout, in case the path resides on a network file system and the server is unreachable. So it's not a completely unreasonable thing to do. On the other hand, the cost in lost backwards compatibility with applications that do not know about this behavior appears to be pretty high, as this thread shows. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill