This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 11/17/2016 02:56 PM, Zack Weinberg wrote:
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 <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).What I'm asking for is evidence that that is actually a problem for at least one real application.
I found this: <https://opensource.apple.com/source/ppp/ppp-412.3/Helpers/vpnd/ipsecoptions.c>ipsec_resolver_thread reads from /dev/random, which can block for a very long time. The thread for it is spawned in ipsec_process_prefs, which cancels it when got_terminate returns true. The intent seems to be that is terminated on graceful process termination: read in ipsec_process_prefs returns EINTR after a signal handler has run which makes got_terminate (defined in main.c in the parent directory) return true.
If the read from /dev/random is replaced with a call to getrandom which is not a cancellation point, this would like not work as intended.
Is this the kind of stuff you are looking for? > Also evidence that making getrandom a
cancellation point _won't_ break programs that naively assume it can never fail.
Cancellation does not add additional error return cases. Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |