What happens to resources on a fork?

[ninja9578]

What happens if I open some sockets or FILEs and then fork?

My assumption is that the original resources will still be useable, but they will be invalid in the child processes. Is that right?

[HighCommander4]

From the man page for fork:

The child inherits copies of the parent's set of open file descriptors. Each file descriptor in the child refers to the same open file description (see open(2)) as the corresponding file descriptor in the parent. This means that the two descriptors share open file status flags, current file offset, and signal-driven I/O attributes (see the description of F_SETOWN and F_SETSIG in fcntl(2)).

I'm no expert, but I think this effectively means that it is safe for either the child or the parent to use the file/socket, but not both (the one that doesn't use it should close() the file descriptor).

[Eri523]

[...] (the one that doesn't use it should close() the file descriptor).

I'm no expert either, but if they share the same open file descriptor, wouldn't then a call to close() affect both of them?

[HighCommander4]

I'm no expert either, but if they share the same open file descriptor, wouldn't then a call to close() affect both of them?

Nope. There is a subtle difference between file descriptors and file descriptions. A file description is data structure in the kernel which stores information about an open file such as the current position. A file descriptor is a number which refers to a file description (most likely just an index into the array of file descriptions maintained by the kernel).

It is thus possible to have multiple file descriptors referring to the same file description. Indeed, looking back at the paragraph I quoted from fork's man page, it says the child inherits copies of the parent's file descriptors, which refer to the same file descriptions.

The question, then, is whether a file description is closed when close() is called on any file descriptor referring to that description, or when close() is called to the last open file descriptor referring to that description. The man page of close() confirms that it is the latter:

If fd is the last file descriptor referring to the underlying open file description (see open(2)), the resources associated with the open file description are freed

P.S.: I guess to implement this, a file description needs to store a reference count of how many file descriptors refer to it. close() would decrement this refcount, and free the description if the refcount reached zero.

[Eri523]

First off, I must admit that I really stepped out of my domain by doing my previous post. In fact, I know close to nothing about *nixes. I was just trying to do some logical thinking...

Maybe I mixed things up with the classical C fopen() which merely returns a FILE *. If we're talking about the open() method of STL streams, chances are good that things are different. The outcome of a call to this method might really be something that carries an internal reference count.

But, to be pedantic, in that case the two objects wouldn't really be the same. Instead, one of them would be the result of calling a copy ctor, or at least something similar...

BTW: The Stroustrup quote in your signature is simply great!

[HighCommander4]

But, to be pedantic, in that case the two objects wouldn't really be the same. Instead, one of them would be the result of calling a copy ctor, or at least something similar...

I never said the file descriptors were the same... The man page I quoted says that one is a copy of the other. On the other hand, they point to the same file description - the file description is not copied.

Hope that clears it up

[Eri523]

Ok, think I now have to step back in shame...

[HighCommander4]

Ok, think I now have to step back in shame...

Don't beat yourself up *nix internals are tricky (well, all OS internals are...)