signal handler for API calls

[GoogleCodeExporter]

This problem was reported by Aaron Brown:

When using the API library, there is no SIGTERM handler that is called if the 
program calling the library is killed.

The specific use case is bwctl calling iperf3 with JSON output. The JSON 
collected so far should be
output (and probably a "killed" message ) when bwctl is killed.

Original issue reported on code.google.com by bltier...@gmail.com on 6 Jan 2014 at 7:16

[GoogleCodeExporter]

There actually is a signal handler, but it wasn't emitting any output beyond 
the error message.  Implemented the desired change (I think) in 5a3b443728a3.

Original comment by bmah@es.net on 6 Jan 2014 at 8:20

• Changed state: Fixed

[GoogleCodeExporter]

Re-open this issue.

Based on private email, the code change in Comment 1 didn't actually add the 
requested functionality, although it did fulfill (my IMHO reasonable 
interpretation of) the problem description.  I need some more information to do 
any further prioritization and/or work on this.

At a minimum:

Which side (client vs. server) do we assume is getting signaled?

Which side (client vs. server) is expected to emit its JSON output when the 
signaling happens?

Does each side emitting output need to grab and display the statistics from the 
other, as in a normal exit?

What about the non-JSON output case?

Basically I need a more complete description of what the expected behavior is, 
so we don't have to continually iterate over this problem.

Original comment by bmah@es.net on 7 Jan 2014 at 5:24

• Changed state: Accepted

[GoogleCodeExporter]

From phone call with Aaron:

bwctl tests involve spawning off both the server and client and allowing them 
to run for some amount of time.  The client gets killed off after a specified 
amount of time...the server is allowed to run for a (slightly) longer amount of 
time, but if it takes too long it may also get killed off.

The interesting output is really on the server side.  If bwctl kills the server 
(say in the case of a network with abysmally bad performance, where it's taking 
the data way too long to get to the server process), we'd like to get the 
accumulated interval statistics on the server, as well as the summary (along 
the lines of what would normally be printed at the end of a normal test).  
These can be printed on the server side.

In this case the client-side statistics (what has been implemented so far) is 
actually less interesting.

Original comment by bmah@es.net on 7 Jan 2014 at 9:48

[GoogleCodeExporter]

Committed a second cut at this in 67173951774c.

Note that we don't actually dump out any statistics on the client if the server 
gets interrupted, and we're doing a normal (not reverse mode) test.  This isn't 
really a requirement per Comment 3, and as noted in the changeset log it's not 
a regression from prior behavior.  However I'm noting it here in case we want 
to leave this bug open (and potentially retarget it) for the remaining work.

Original comment by bmah@es.net on 8 Jan 2014 at 12:11