This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7] getrandom system call wrapper [BZ #17252]
On 11/18/2016 03:21 PM, Torvald Riegel wrote:
As discussed in the thread, there are different opinions about what the
default should be. There are reasonable arguments for both options. In
such a case, it seems better to make the choice explicit, simply from an
ease-of-use and interface design perspective.
Unfortunately, this is not the approach that POSIX has chosen. But
there is precedent for doing our own thing in this area: the "c" flag
for fopen. We cannot use the existing flags argument in getrandom for
this purpose because its layout is controlled by the kernel.
This is not about whether
it's possible for users to do (they could build their own syscall
wrappers after all too, right? ;) ) but about clean interfaces.
It's not possible to opt in to cancellation at system calls using only
public glibc interfaces. The best you can do is to implement
cancellation from scratch, using a different signal.
With your proposal, one could argue that, for example, every library has
to be aware of cancellation and how it works if one of the clients of
the library could want to use cancellation;
But that is true for most libraries today, no matter what we do about
getrandom. getrandom just does not add significant additional exposure
in this area.
the library either has to
disable it explicitly, or it has to document which additional
cancellation points exist and has to implement the cleanup handlers.
This is error-prone and adds complexity to those use cases. Therefore,
it seems better to avoid that potential source of bugs and either make
the default to not support cancellation (ie, an opt-in for the
cancellation facility), or make at least make the choice explicit for
users of getrandom (ie, two functions or an additional parameter).
I'm increasingly worried that this discussion is actually about thread
cancellation in general and only peripherally about getrandom.
Considering the fringe nature of getrandom (it is intended for the
implementation of PRNG seeding, after all), it seems to be a strange
choice to attempt to settle this debate.
Does POSIX even say that cancellation has to be enabled for new threads
by default, like we do? It's probably too late to change this.
In the end, this is very similar to the ongoing debate about exception
handling in C++ and other languages. For most such languages, there are
large code bases which ban exceptions for various reasons, and others
which use them with success. I don't think we can reach agreement which
one application developers should prefer. The only thing we can do is
try to be as consistent as possible (and for getrandom, I think the
model should be the read function, and not rand).
This discussion is also blocking further work on my part for additional
randomness generation functions. More user-oriented interfaces we could
add, such as getentropy or arc4random, should *not* be cancellation
points, I think.
Thanks,
Florian