From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27000 invoked by alias); 18 Nov 2016 15:46:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 26988 invoked by uid 89); 18 Nov 2016 15:46:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=crude, Hence, cancel, blocked X-HELO: mx1.redhat.com Message-ID: <1479483971.7146.1186.camel@localhost.localdomain> Subject: Re: [PATCH v7] getrandom system call wrapper [BZ #17252] From: Torvald Riegel To: Szabolcs Nagy Cc: Zack Weinberg , Florian Weimer , nd@arm.com, GNU C Library Date: Fri, 18 Nov 2016 15:46:00 -0000 In-Reply-To: <582ED78F.3050400@arm.com> References: <3dd5d3b8-c196-98fb-1671-90cd90ab90c7@redhat.com> <244f578c-889a-a4cf-c686-bb2a5e49cca1@panix.com> <2d175242-1a82-9410-d01e-682ab4d9081e@panix.com> <0cca2fc9-14d2-9fa2-5a6e-fe00af31acd6@redhat.com> <4928b864-9691-021d-fcf9-b3ef9bd10f63@panix.com> <5193b776-03a5-3841-6980-b67c56a99c2a@redhat.com> <582ED78F.3050400@arm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00661.txt.bz2 On Fri, 2016-11-18 at 10:27 +0000, Szabolcs Nagy wrote: > blocking syscalls have to be cancellation points > otherwise they cannot be called safely from a long > running process that has to remain responsive: > blocked threads can keep piling up and there is no > way to reuse the resources they hold. > > [this is the general argument for adding new > blocking syscalls as cancellation points]. You are describing just *one* use case. You also don't define what "remain responsive" is supposed to mean; there's a difference between being able to cancel any time vs. ensuring that a syscall will not block indefinitely (eg, I think the common case for getrandom should be that it does not block indefinitely, and scenarios in which no randomness can be found nor "generated" are corner cases). Related to that, you don't distinguish between what can be done to recover when a particular syscall does not complete; for example, is there likely to be a workaround for a getrandom that does complete, or is calling exit() the most likely response. You also don't discuss who the expected audience for a syscall wrapper is. How likely it is that they are aware of cancellation, might make use of it, etc.? How likely is the syscall going to be used directly vs. being hidden by another wrapper that is produced by developers that understand cancellation? Just the fact that there are all these different considerations suggests that there's no clean one-size-fits-all interface. Hence my suggestion to at least make the choice explicit (and thus obvious to users), for example by either an additional parameter or by providing two wrappers. If there is in fact no good default or one-size-fits-all, we should not pretend that there is. Finally, pthreads cancellation is a pretty crude means to build asynchronous / cancellable operations because you cannot cancel just a particular call; you always cancel a thread, which means that in general, you need additional synchronization or other constraints to make sure that you do not cancel at another cancellation point in some other unrelated operation executed by the same thread.