Hmm,
So we were looking at NetBSD's ping6 for inclusion in rumprun. ping6
does essentially:
signal(SIGALRM, thehand);
setitimer(...);
rv = poll(..., -1);
if (rv == -1 && errno == EINTR) {
...
}
Now, it's easy enough to get a rump kernel to deliver a host SIGALRM for
both local and remote clients (in fact, it happens already -- at least
on POSIX hosts).
However, that does not take care of interrupting the rump kernel syscall
to return EINTR. That said, rump kernels already support interrupting
syscall sleeps because that was required for correct thread+exec
semantics. Even though signals could more or less use the same facility
as exec, there's another problem: to properly decide whether the syscall
can be interrupted, we'd need to track, among other things, the signal
mask. Doing signals properly would mean adding sigprocmask() and that
family of calls. Maintaining two signal masks (rump kernel and host)
might get quite confusing quickly. Confusion would only be compounded
by the fact that not all hosts even have signals.
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")
I'm inclined to do "2" (because that's the least amount of work ;). The
creative way NetBSD's ping6 avoids the timeout argument to poll() would
have to be changed, and while changing an existing, real-world program
pains me a bit, I'd hate taking on loads of extra complexity for solving
a niche issue.
Comments?
------------------------------------------------------------------------------
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
