• View
• Edit
• History
• Print

SignalTiming

Timing Signals to Orphaned Processes

February 14, 2015

The Problem

Notice the two blue points on the far left in the inset.

It starts with a graph. The read points in the graph to the right are meant to give a baseline: these are timings for a command loop in my system which uses triple module redundancy. The blue points are from a different configuration in which I am just timing how long it takes a component to be restarted.

As you can see, the amount of time it takes is rather long. And worse, it gets longer as the number of restarts increases. I know that time does not lie within the fork() call, as I have already investigated and patched this problem: Kernel Data Structures.

Of particular are the first two blue dots, which I have tried to display in the inset. The first timing measurement is about 550 µ-seconds and the next takes about 450 µ-seconds. This seems to indicate that the signal timing only becomes problematic when the signaled process is not related to the signaler or is an orphan. These are just clues with a few hunches that are bias by my previous problems. There is always the possibility that there is something wrong with my code (priorities, perhaps?).

Minimal Example

The minimal example is complete, but it does not demonstrate the behavior. The program creates a long chain of orphans, and then times the signals from the original to the last. For better or for worse, it seems that signal timing is completely reasonable. The problem must lie elsewhere.

Some nifty things to know:

• RT signal numbers should be specified as SIGRTMIN + x and checked that they are not over RTSIGMAX. Something to do with some libraries reserving some RT signals.
• RT signals allow for the handler to receive a union sigval with either an int or a pointer through sigqueue.
• The pid_t of the sending process may be retrieved in the handler via siginfo_t.si_pid.
• If you don't have a handler for an RT signal, the default behavior is to terminate. Other signals have different defaults: http://man7.org/linux/man-pages/man7/signal.7.html

So, at least I learned a bit more about signals (see the code).

RT-Signals vs Signals

While I'm at it, why not compare RT-Signals to normal ones? Unfortunately I am using the RT-Signal data passing feature to pass a timestamp. To test a regular signal I would have to come up with a different method of testing. This is not trivial since two separate process would need to take a timestamp and communicate it somehow.

I can fairly easily test the difference between RT-Signals between related processes and between a ancestor and orphan.

Also testable is how RT-Signals perform in a non-RT kernel - as one would expect the non-rt kernel performs better on average. WCET is about the same, with the except of on or two horrible cases for the RT-kernel. The system had a very low load, so a fair comparison would have a high workload which stresses the system.

But I need to move on, so this will have to wait.