[LITMUS^RT] Supporting Job Aborts

[Christopher Kenna]

On Thu, Sep 6, 2012 at 6:34 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> (POLLING) An obvious solution to this problem is to write budget expiration flags to a control page from within Litmus.

I think an asynchronous approach is better than polling because of the
extra overhead involved and the fact that long time periods could
elapse between polls.

> (Disjoint Range for Litmus Signals)

I think this is the best choice in theory, but the implementation is
very ugly. I don't think that we should rely on any of the proposed
options of setting up a system call correctly (breaks the signal
abstraction), relying on double-underscore functions to do work (will
most certainly break quickly), or bypassing the post-signal-handler
routine without knowing what it does in detail.

> (Overlapping Range for Litmus Signals)

This seems like the best option considering the pros/cons of the other
two. Normally, I would say that repurposing signals that a standard
says _should_ be available to user programs would be a bad thing, but
I think it would be reasonable to do this here. I did find one source
[1] stating that the standard only requires 8 real-time signals, so
Linux has enough already.

The real-time signals contain an additional data field that may be
used by the application to exchange data between the signal generator
and the signal handler. For example, this data field may be used to
identify the source of the signal. Maybe we could multiplex a bunch of
different messages under just one "LITMUS^RT" signal and decrease
SIGRTMAX by just one.

 -- Chris

[1] http://www.kernel.org/doc/man-pages/online/pages/man7/signal.7.html