Check out the new USENIX Web site. next up previous
Next: Linux process internal environment Up: Linux process external environment Previous: Reproducing the fd and


Signals

Signal delivery in K42's Linux application environment differs from most implementations in that most operations can be carried out without kernel involvement. State information such as signal masks, sigaction specifications (ignore, default action, or handler to call when signal arrives), and set of pending signals, is kept in the application's address space. Operations such as sigsuspend and pause simply block in the client without any interaction with the kernel.

Inter-process signal delivery goes through the ProcessLinuxServer. The target K42 process is identified, and in the general case, the server delivers the signal to the client through an IPC. For signals that can not be ignored (SIGKILL, SIGSTOP), the server contacts the kernel.

Intra-process signal delivery is carried out entirely in the client space. This results in significant performance advantages for the current implementation of Linux Threads[19], which uses signals to implement synchronization among threads. In the upcoming Linux threads package(NPTL)[10], synchronization is implemented using the futex (fast light-weight user-space semaphores) kernel synchronization service. Although futexes are more lightweight than the current implementation, they still involve kernel interaction. With the new threading model, we still expect to be able to implement the synchronization at user level.


next up previous
Next: Linux process internal environment Up: Linux process external environment Previous: Reproducing the fd and
2003-04-08