Check out the new USENIX Web site. next up previous
Next: Signals Up: Linux process external environment Previous: Reproducing the memory image


Reproducing the fd and signal state on a fork

In addition to reproducing the memory in the forked child, the filesystem state and signal state must also be copied. Most of this state is replicated during the reproduction of the memory state. A mechanism is needed to indicate the child is now using the files referenced by the open fds and to receive the signals set up by the handlers.

In Unix, after a fork, the kernel indicates the child is using the files by traversing the fd list and incrementing the usage count on each of the files pointed to by that fd list. As mentioned above, in K42 there is an individual object instance that manages each file. User-space FileLinuxFile objects have permission to talk to the underlying file through the objectRef they hold to that file. The vast majority of calls to fork are followed by calls to exec in the forked child. In K42, we lazily provide permission to each of the files in the child. In the common case of a succeeding exec, we therefore avoid the work altogether. In Unix, this would be equivalent to not actually updating the reference count until an access is made (but also being careful to not decrement the count if no reference is made). In K42 we accomplish this by creating an object in the kernel to represent the client file being reproduced in the child. In a fork intensive workload, where many files are not accessed after fork, we pay the same overhead as a kernel implementation like Linux (because the parent pushes this information to the kernel), but, when files start being used, the K42 kernel interacts with the server to perform a proper setup (the child lazily initializes the structures), and from then on we get the advantages of our user-level implementation.

The signal state of the parent is copied to the child entirely by the memory reproduction. Thus, all signal handlers installed in the parent are reproduced in the child. The disposition of pending signals due to, for example asynchronous I/O, is undefined. In K42 the signal will be delivered only to the old object that was originally waiting for it.


next up previous
Next: Signals Up: Linux process external environment Previous: Reproducing the memory image
2003-04-08