Re: [TUHS] Unix APIs: elegant or not?

[Dave Horsfall <dave@horsfall.org>]

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