Issue #1384: Refactor some common code in the Timer API for legibilit…

[Castaglia]

…y/tracing, and add trace logging of alarm blocking.

[Castaglia]

If alarms are blocked, we shouldn't enter the while loop at all. Previously, we'd enter the while loop, set nalarms = 0, and then check whether alarms were blocked. If they were, then perhaps the SIGALRM signal which triggered this function call might not be properly handled, and in fact may have been "forgotten" due to the nalarms = 0 setting. Perhaps that might be the cause of some of the symptoms/behaviors reported in this issue?

Note to self: It is possible to handle a SIGALRM signal while alarms are blocked; due to the ordering of signal handling in the ProFTPD code, pr_alarms_blocked() could be called after the SIGALRM signal is received, and before it is processed.

[Castaglia]

Turns out that attempting to use pr_trace_msg() in the pr_alarms_block() function leads to a stack overflow, since the trace logging code calls into the Pools API, which blocks alarms, which calls the trace logging code, etc.

To avoid this -- and to honor what the Pools API really needs here -- we block signals, rather than alarms. And this is more desirable, as pr_alarms_block() does not block SIGARLM signals, it only blocks the processing of the timer callbacks. In these Pool routines, we don't want interruptions at all via signals, thus pr_signals_block() is better here anyway.

[Castaglia]

The follow-on, then, is that we cannot call pr_trace_msg() within the pr_signals_block() functions, either, lest we trigger the same stack overflow!