On Fri, Feb 21, 2014 at 4:42 PM, Antti Kantee <[email protected]> wrote: > 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.
That seems like a fairly weak justification. I am becoming more inclined to go for option 3 now... If there are no syscalls that generate signals (itimer etc) and its all there just for SIGXFSZ which is not really needed as a signal, then its just much simpler to remove it all. None of these generated signals dont also have perfect;y good return codes if the signal is not delivered. Justin ------------------------------------------------------------------------------ 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
