On Sun, 4 Nov 2018, Noel Chiappa wrote:
"Virtually". Maybe there are places that
want to know if their read call
was interrupted; if you don't make this version available to them, how
can they tell? Leaving the user as much choice as possible is the only
way to go, IMO; why force them to do it the way _you_ think is best?
I certainly don't want the kernel making that decision for me; I might
want to abandon the entire read() if I was signalled. I did write some
code that did that, but I've long since forgotten the details.
And it makes the OS simpler; any time you can move
functionality out of
the OS, to the user, that's a Good Thing, IMO. There's nothing stopping
people from using the EINTR-hiding wrapper. (Does the Standard I/O
library do this, does anyone know?)
Agreed; the kernel should make as few decisions as possible, and I've used
variations on that wrapper, depending on the signal etc.
PS: Only system calls that can block can return EINTR;
there are quite a
few that don't, not sure what the counts are in modern Unix.
Almost invariably serial lines, and I used to do a lot of that code.
-- Dave