[TUHS] Unix APIs: elegant or not?
dave at horsfall.org
Mon Nov 5 14:04:52 AEST 2018
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.
More information about the TUHS