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

[Zack Weinberg <zackw at panix dot com>]

On Wed, Nov 16, 2016 at 10:52 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 11/16/2016 04:20 PM, Zack Weinberg wrote:
>> I am seriously considering escalating my disagreement here to a
>> formal objection.  I would like to know why you think it is
>> NECESSARY - not merely convenient or consistent with other stuff -
>> for this function to be a cancellation point.
>
> It's necessary if you ever want to cancel a hanging getrandom in a
> context where you cannot install a signal handler (so that you can
> trigger EINTR when getrandom is stuck).

That only pushes the question back a level.  When would it ever be
necessary to do that?  Be as concrete as you possibly can.  Actual
code from a real program, if possible.

> I really don't understand why cancellation points are widely
> considered as evil.  Most code does not use cancellation in a
> correct way, and it will not improve if we simply stop adding new
> cancellation points.

I would argue that most code does not use cancellation correctly in
large part _because_ the set of cancellation points is so large and
amorphous.  It is the same problem that people have with exceptions in
C++; because practically everything you might do exposes you to
cancellation, it's so difficult to know how to write cancel-safe code
that people just apply the big hammer of not using it at all.  Another
useful example is multithreading versus coroutines with explicit yield
points---the latter can be less efficient and/or more verbose, but
it's so much easier to debug that it's worth it.

There's not a lot we can do about the cancellation-point set in POSIX
being so large, but we can at least not make things worse, by not
adding additional cancellation points.

> at least in library code, it is impossible to introduce cancellation
> into a system call where the wrapper does not support it (because
> you cannot fake your own version of cancellation with a do-nothing
> signal handler).

>From the perspective that as few operations as possible should be
cancellation points, this is a Good Thing.  And I don't see why it
would be a problem for getrandom in particular.

zw