Timo Sirainen wrote, On 10/19/09 6:11 PM:
On Mon, 2009-10-19 at 17:55 -0400, Timo Sirainen wrote:
Can someone find an OS where the attached program doesn't work? It
should print "success". So far tested for success: Linux 2.6, Solaris
10, FreeBSD 7.2, OpenBSD 4.2.
And also: I think (guess) that behavior is required by POSIX, but it
would be nice if someone could verify that. :) The behavior being:
seeking in a fd is affects all processes that have the same fd open.
(Simple IPC, yay.)
As I read them, the various man pages for dup() confirm that. In addition to
those man pages' statements about standards compliance, the fact that dup()
is in 4BSD's unistd.h is also a strong clue. When looking for this sort of
info, an invaluable resource is the man page archive at
http://www.freebsd.org/cgi/man.cgi which has man collections from many
different branches of the Unix family tree going back to Unix 7th edition
and BSD 2.8.
It is useful for people who don't routinely work with file access code to
note that "same fd" means significantly more than "same file" so it isn't as
simple as having processes open() the same file. One man page for dup() says
this:
The object referenced by the descriptor does not distinguish between
fildes and fildes2 in any way. Thus if fildes2 and fildes are
duplicate references to an open file, read(2), write(2) and lseek(2)
calls all move a single pointer into the file, and append mode,
non-blocking I/O and asynchronous I/O options are shared between the
references. If a separate pointer into the file is desired, a
different object reference to the file must be obtained by issuing an
additional open(2) call. The close-on-exec flag on the new file
descriptor is unset.
