Unix Programming - The strange properties of fork()...

Author

The strange properties of fork()...

Anonymous

2004-08-22, 6:08 pm

I've been writing some experimental UNIX programs in order to get a
better understanding of how it works and I am surprised by some of the
results and would like to ensure that my understanding is correct.
I guess there are two things that surprise me about fork(). One is that
all file descriptors are copied and it doesn't appear to matter what type of
files these descriptors reference. For instance, while I would expect disk
file descriptors to be copied safely, I didn't expect pipes to! Nor did I
expect listening sockets to get copied as well! I thought (perhaps,
incorrectly) that two sockets couldn't even be bound (using bind()) to the
same port, let alone both be listening but it appears that such a situation
is easily possible using fork(). With the pipes, the descriptors really do
reference the same file so when one process reads, the file pointer gets
incremented and the other process can't get that data (instead of the file
buffer being duplicated). With listening sockets, it's natural to ask which
process gets the connection. The answer is (I'm certain) the one that
happens to call accept() first. Can anyone shed any insight into this?
The other thing that surprises me about fork() is what happens to the
process' threads. One might imagine that the threads get copied as well but
it turns out that they do not. A natural question would then be which
thread gets copied? Well, the one that called fork(), of course! These are
all surprises to me. What happens to the resources used up by the other
threads, like local storage the stuff? My theory is that, despite how only
one thread gets copied, all the data pages get copied, including the thread
stacks and the heap management data. While you can carefully engineer your
program to save the resources and close up all your file descriptors used by
the threads, nothing can save you from leaking the thread stacks. Does this
assessment agree with anyone's understanding? Does anyone disagree? Is
anyone else suprised by these findings, as well? Can anyone shed more light
on this subject?
Thank you for reading and your kind input...

Rich Teer

2004-08-22, 6:08 pm

On Fri, 20 Aug 2004, Anonymous wrote:

> I guess there are two things that surprise me about fork(). One is that
> all file descriptors are copied and it doesn't appear to matter what type of

That's because apart from deep down inside the kernel somewhere, fork()
has no idea what type of file a descriptor refers to. Descriptors just
refer to vnodes, which by design are independant of file and file system
type.

> files these descriptors reference. For instance, while I would expect disk
> file descriptors to be copied safely, I didn't expect pipes to! Nor did I

Why not? How else would a parent and child communicate via a pipe?!

> process gets the connection. The answer is (I'm certain) the one that
> happens to call accept() first. Can anyone shed any insight into this?

Read the Stevens' books. :-)

> The other thing that surprises me about fork() is what happens to the
> process' threads. One might imagine that the threads get copied as well but
> it turns out that they do not. A natural question would then be which
> thread gets copied? Well, the one that called fork(), of course! These are
> all surprises to me. What happens to the resources used up by the other
> threads, like local storage the stuff? My theory is that, despite how only

In the parent they're untouched (of course), and they don't exist in
the child.

> one thread gets copied, all the data pages get copied, including the thread

Why would that be? Copying all the thread specific data for all threads,
when you only copy one thread is a bad design.

> stacks and the heap management data. While you can carefully engineer your
> program to save the resources and close up all your file descriptors used by
> the threads, nothing can save you from leaking the thread stacks. Does this
> assessment agree with anyone's understanding? Does anyone disagree? Is

I think you're not quite understanding what fork does. It merely makes a
copy of the calling process (including just the calling thread in the case
of a MT process). Very little data is actually "copied"; the pages themselves
are marked Copy On Write.

> anyone else suprised by these findings, as well? Can anyone shed more light
> on this subject?

Yes; please order a copy of my book from the following link:

URL: http://www.rite-group.com/rich/ssp

Programming with POSIX Threads by Dave Butenhof is also worth a look,
as are the Stevens books for network programming stuff.

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
publishing in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

Michael J. Malone

2004-08-22, 6:08 pm

> Yes; please order a copy of my book from the following link:
>
> URL: http://www.rite-group.com/rich/ssp
>
> programming with POSIX Threads by Dave Butenhof is also worth a look,
> as are the Stevens books for network programming stuff.

This is a bit off topic, sorry if it is inappropriate. Rich, do you
know if your book will be available through the 'safari' online books
site (http://safari.oreilly.com)? If so, when?

Looks like a good read,

Thanks,

-Mike

Rich Teer

2004-08-23, 8:01 am

On Sun, 22 Aug 2004, Michael J. Malone wrote:

> This is a bit off topic, sorry if it is inappropriate. Rich, do you
> know if your book will be available through the 'safari' online books
> site (http://safari.oreilly.com)? If so, when?

Very unlikely, given that it's published by Prentice Hall.

> Looks like a good read,

Thanks!

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming",
published in August 2004.

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich