[ovs-dev] [PATCH] Make fatal signals cause an exit more promptly in special cases.

Jesse Gross jesse at nicira.com
Tue Apr 13 15:46:01 UTC 2010

On Mon, Apr 12, 2010 at 5:47 PM, Ben Pfaff <blp at nicira.com> wrote:

> The fatal-signal library notices and records fatal signals (e.g. SIGTERM)
> and terminates the process on the next trip through poll_block().  But
> some special utilities do not always invoke poll_block() promptly, e.g.
> "ovs-ofctl monitor" does not call poll_block() as long as OpenFlow messages
> are available.  But these special cases seem like they are all likely to
> call into functions that themselves block (those with "_block" in their
> names).  So make a new rule that such functions should always call
> fatal_signal_run(), either directly or through poll_block().  This commit
> implements and documents that rule.

Thanks for tracking these down.  Looks good, just one comment:

> +/* Check whether a fatal signal has occurred and, if so, call the fatal
> signal
> + * hooks and exit.
> + *
> + * This function is called automatically by poll_block(), but specialized
> + * programs that may not always call poll_block() on a regular basis
> should
> + * also call it periodically.  (Therefore, any function with "block" in
> its
> + * name is a candidate to call fatal_signal_run(), because such functions
> can
> + * only used by specialize programs that can afford to block outside their
> main
> + * loop around poll_block().)
> + */

Are these all the *_block functions?  Can we just say that any *_block
function *must* call poll_block() (rather than is a candidate to call it)
and that way we don't have to go digging through the code to verify it when
we write one of these programs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100413/327816a1/attachment-0003.html>

More information about the dev mailing list