Friday, September 03, 2010

Two things every Unix developer should know

Unix programming can be tricky. There are many subtleties many developers are not aware of. In this post, I will describe just two of them... my favorite Unix quirks, if you will.

Interruptible system calls

On Unix, any system call which blocks can potentially fail with an errno of EINTR, which indicates that the caller must retry the system call. The EINTR error can be raised at any time for any reason, so essentially every I/O operation on a Unix system must be prepared to handle this error properly. Surprisingly to some, this includes the C standard library functions such as fread(), fwrite(), and so on.

For example, if you are writing a network server, then most of the time, you want to ignore the SIGPIPE signal which is raised when the client closes its end of a socket. However, this ignored signal can cause some pending I/O in the server to return EINTR.

A commonly-held belief is that setting the SA_RESTART flag with the sigaction() system call means that if that signal is delivered, system calls are restarted for you and EINTR doesn't need to be handled. Unfortunately this is not true. The reason is that certain signals are unmaskable. For instance, on Mac OS X, if your process is blocking reading on standard input, and the user suspends the program by sending it SIGSTOP (usually by pressing ^Z in the terminal), then upon resumption, your read() call will immediately fail with EINTR.

Don't believe me? The Mac OS X cat program is not actually interrupt-safe, and has this bug. Run cat with no arguments in a terminal, press ^Z, then type %1, and you'll get an error from cat!

$ cat
^Z
[1]+ Stopped cat
$ %1
cat
cat: stdin: Interrupted system call
$

As far as I'm aware, Factor properly handles interruptible system calls, and has for a while now, thanks to Doug Coleman explaining the issue to me 4 years ago. Not having to deal with crap like this (not to mention being able to write cross-platform code that runs on both Unix and Windows) is one of the advantages of using a high-level language like Factor or Java over C.

Subprocesses inherit semi-random things from the parent process

When you fork() your process, various things are copied from the parent to the child; environment variables, file descriptors, the ignored signal mask, and so on. Less obvious is the fact that exec() doesn't reset everything. If shared file descriptors such as stdin and stdout were set to non-blocking in the parent, the child will start with these descriptors non-blocking also, which will most likely break most programs. I've blogged about this problem before.

A similar issue is that if you elect to ignore certain signals with the SIG_IGN action using sigaction(), then subprocesses will inherit this behavior. Again, this can break processes. Until yesterday, Factor would ignore SIGPIPE using this mechanism, and child processes spawned with the io.launcher vocabulary that expected to receive SIGPIPE would not work properly. There are various workarounds; you can reset the signal mask before the exec() call, or you can do what I did in Factor, and ignore the signal by giving it an empty signal handler instead of a SIG_IGN action.

7 comments:

Brian Williams said...

Fascinating, never knew that. You are on the front page of the programming reddit by the way.

http://www.reddit.com/r/programming/comments/d9h0a/two_things_every_unix_developer_should_know/

rjbond3rd said...

>>When you fork() your process, various things are copied from the child to the parent;

Interesting article. You might have intended "from the parent to the child"?

fork-sucks said...

Fork also acts differently on different platform. Especially for performance. If you using a lame brain Unix it is likely that your fork is a neutered compared to Linux.

Often you'll need to exec after a fork in unix just to be safe. So dup your file handles and exec.

Because linux doesn't use threads the same way as FreeBSD, Solaris and OSX, Linux forks are a bit easier to deal with and you don't need to exec after a fork (but you should clean up).

A programming language should provide this exec for you such that you can have code that can return to a parent or child position without much trouble

DiG said...

Use macports GNU/cat, if you want to work around this bug :)

$ /bin/cat
^Z
[1]+ Stopped /bin/cat
$ %1
/bin/cat
cat: stdin: Interrupted system call
$ /opt/local/bin/cat
^Z
[1]+ Stopped /opt/local/bin/cat
$ %1
/opt/local/bin/cat
^C
$

mike said...

The non-blocking file descriptor thing is actually far worse than you think. Non-blocking is not inherited, it is a shared flag. In other words, even if you set the descriptor to be non-blocking after it gets inherited by your child process, the child's copy will spontaneously become non-blocking as well.

It's basically impossible to correctly use non-blocking file descriptors on anything you didn't create yourself and are careful not to share.

Cathy Mena said...

Yes you are right without knowing these things we can not say that he have complete knowledge of developing.

Vladimir Sedach said...

The right thing to do with blocking system calls is what's known as PCLSRing in ITS (http://en.wikipedia.org/wiki/PCLSRing) - that is, system calls should be transparently restartable. I think only ITS and the Lisp Machines did this properly.

With regards to fork(), Unix has even more brain damage in store when your process has multiple threads running: http://fare.livejournal.com/148185.html

The "Unix philosophy" of system programming seems to be "Write 300 system calls that do similar things for no reason with subtly different but equally useless interfaces, and make sure they all happen to be fucking broken."