Re: [PATCH v7] getrandom system call wrapper [BZ #17252]

[Torvald Riegel <triegel at redhat dot com>]

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.