On 21/02/14 12:13, Justin Cormack wrote: >> The options I can see are: >> 1) make signals completely mimic POSIX (and fix bugs forever) >> 2) leave things as they currently are (rump kernels make a reasonable >> effort to cater to signal-happy programs, though semantics are so-so) >> 3) completely rip out any host signal delivery (equally good/bad for all >> hosts, and does not give a false sense of "1") >> > Not sure, 2 or 3 seem valid. Is there a description of exactly what works > under 2? I haven't actually knowingly used signals under rump.
First of all, there are several signal "models" that you can select for a rump kernel by calling rump_boot_setsigmodel(): panic, ignore, record and raise. The first three are hopefully obvious (if not, see src/sys/rump/librump/rumpkern/signals.c). I'm talking about the last one (raise), which is also the default model. A signal can be delivered either to a local client or a remote client. The signal is raised in the host container (if available). On POSIX hosts it's simply raise(), and called either via rumpuser_kill() or the RUMPSP_RAISE PDU for local or remote clients, respectively. This is what works and happen by default. It's not very many lines of code (~10'ish). As I mentioned in the previous mail, the other part is tracking signal masks per rump kernel process (well, thread) context and interrupting syscalls when a signal is delivered (iff the syscall is interruptable). This is what doesn't work and would be quite a few lines of code. I think I originally implemented the "raise" signal model so that SIGXFSZ from a file system could be tested. Even with several years of hindsight, I'm not sure if implementing it was a mistake, pretty much confirming that deciding what "the right thing to do" is not easy here. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
