[email protected] said:
> Right, but signals is something that should be attacked critically,
> not just bend over and emulating the existing concept. This whole
> work is pointless if the end result is what is known as an OS ;)
I do NOT want to be doing a full-blown signals implementation. What I do
want (and the problem I'm trying to solve) is to be able to shutdown an
application cleanly, using either "xl shutdown", ACPI poweroff, magic
packet or whatever.
The accepted way to cleanly shutdown a well-behaved POSIX application is to
send it SIGTERM, wait a while and possibly send it SIGKILL if it doesn't
get its act together.
Here's a naive way of how I think this could work. This is likely to be
full of race conditions or potential deadlocks, but I want to get it on the
table anyway:
1) We implement a sigaction() which allows setting a SIGTERM handler and
ignores any other operations.
2) (Xen-specific, but other platforms will work similarly). We reinstate
the mini-os shutdown thread from upstream. This waits on a xenbus watch for
the "xl shutdown" signal.
3) When we receive a shutdown signal, the following needs to happen, in
this order:
a) We run the application's SIGTERM handler if set, in the context of
the shutdown thread.
b) We unblock any application threads waiting inside the Rump Kernel,
with all calls returning EINTR.
This should be enough for a well-behaved application to figure out that
it's supposed to terminate.
4) (This needs to be added to normal _exit() / abort() / after callmain
handling anyway). We close all open file descriptors, and do a chdir("/"),
so that rumpconfig can cleanly unmount filesystems and down network
interfaces.
Is this possible? Specifically, step 3) b)?
Separately, but related, as I have found with MySQL's normal shutdown
process, we will also need to implement pthread_kill(thread, SIGKILL).
-mato
