This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v7] getrandom system call wrapper [BZ #17252]
On 11/17/2016 08:50 AM, Florian Weimer wrote:
> 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 <firstname.lastname@example.org>
>>>>> 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
> 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
What I'm asking for is evidence that that is actually a problem for at
least one real application. Also evidence that making getrandom a
cancellation point _won't_ break programs that naively assume it can