Ghosts of Unix past, part 2: Conflated designs

Posted Nov 5, 2010 11:45 UTC (Fri) by RobSeace (subscriber, #4435)
In reply to: Ghosts of Unix past, part 2: Conflated designs by Yorick
Parent article: Ghosts of Unix past, part 2: Conflated designs

> Anyone who has tried to do, say, non-blocking reads and blocking writes on
> the same socket (especially in different threads) knows about this. Having
> a flag in read()/write() (etc) would be better in all respects, not least
> for code understanding and review.

Well, for sockets you already have this as a recv()/send() flag: MSG_DONTWAIT... So, it's really only an issue for non-socket FDs; and, that would require some kind of new I/O functions which took flags like recv()/send() do, in order to solve... (Or, just make recv()/send() work on non-socket FDs?)

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 5, 2010 12:58 UTC (Fri) by Yorick (guest, #19241) [Link] (1 responses)

Yes, it is a bit annoying that send/recv only work for sockets. And the mere existence of a per-descriptor NONBLOCK flag is enough to make it much harder to see whether a given call to read()/write() is likely to block or not.

More to the point, there is an ever-growing set of I/O syscalls doing essentially the same thing, none being a clear super-set of the rest; read/write, pread/pwrite, readv/writev, preadv/pwritev, send/recv, sendto/recvfrom, sendmsg/recvmsg... There were good reasons for every addition, but there is a clear lack of orthogonality and no single general call the remaining can be defined in terms of.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 12, 2010 23:08 UTC (Fri) by giraffedata (guest, #1954) [Link]

I agree that in many cases, the non-blockingness is a property of the read, and not the file descriptor. But making it an argument of read() instead of a file descriptor attribute would violate a fundamental Unix principle, covered in the first article of this series: that of the generic byte stream.

In some cases, you want a piece of code to be agnostic of blocking, just as it is agnostic to socket vs tape drive. The code neither knows nor cares whether its read will block or return zero bytes. It's the caller's business alone.

So I would like to see both. The pread() situation is quite analogous: pread() extends the simple byte stream with the concept of stream position, but another program can still remain agnostic to position, using classic read() while its caller manipulates position with lseek().