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

[Florian Weimer <fweimer at redhat dot com>]

On 11/17/2016 02:45 PM, Zack Weinberg wrote:
> On 11/17/2016 08:02 AM, Florian Weimer wrote:
> > On 11/16/2016 05:41 PM, Zack Weinberg wrote:
> > > 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.
> >
> > It's not clear to me what you are asking here.
> >
> > Do you mean cancellation in general, or cancellation in conjunction with
> > getrandom specifically?
>
> Sorry.  I meant cancellation specifically of a thread hanging in getrandom.

I'm not sure how I can provide that, considering that there is currently 
no way to cancel a thread which hangs in getrandom because we do not 
provide a way for applications to implement system calls as cancellation 
points (unless we provide a wrapper for the specific system call, of 
course).

Florian