Everyone knows what ^D does on Unix; it generates an end of file,so that cat or various other programs will exit (especially ifthey have accidentally wound up reading from standard input ).

But this is just the usual effects of typing ^D; it is not whatit actually does. What ^D actually does is simple but subtle:

Typing ^D causes the tty driver to immediately finish a read() .

Normally doing a read() from a terminal is line-buffered inside thetty

Given the problems that the POSIX EINTR stuff causes to various programs, one might wonder why they existat all. Why not make all system calls restart when signals aredelivered?

What I believe it comes down to is library safety.

Suppose that your signal handler wants to change the main flow ofthe program. There are two plausible mechanisms for this: you canimmediately transfer control back to the main flow of your program withsome changes (the traditional setjmp()/longjmp() approach), or you can

We have a lot of NFS filesystems and, like most people today, we use NFSover TCP instead of over UDP. But this leads to a problem; sometimeswhen our systems reboot, they can't mount all of the NFS filesystems onthe first attempt. It generally takes several minutes to get to a statewhere all of them are mounted.

(We don't use the automounter, so we mount everything at boot; we have our own solution for the problemsthe automounter is trying to solve.

Here is a thought and a theory that has recently struck me.

One reason that writing secure programs is hard is because programmershave a kind of blindness about our own code. Instead of seeing the codeas it really is, we tend to see the code as we imagine it in our heads,and as a result we see what we wrote it to do, not what it actuallydoes.

(This is not usually a literal blindness, although we can do that too,but a disconnect between what the the