On 5 Sep, Bruce Evans wrote:
> snprintf, strlen, vsnprintf, sysctl, sysctlbyname
>
> I think all of these are safe in practice.
>
> It also accesses some variables that are not safe to access in
> a signal handler (non-auto ones that are not of type "volatile
> sig_atomic_t" or are accessed by reads). This is unsafe in practice.
> E.g., concurrent calls to setproctitle() might corrupt the state of
> the ps_strings variable.
Mmm, I don't know what those strings are used for -- what's the worst,
that could happen here -- corrupted PS output, or worse?
In any case, it seems, like a simple lock -- a static variable in the
signal handler would work:
static signal_handling;
...
if (signal_handling)
return;
if (signal)
signal_handling = 1;
...
signal_handling = 0;
Or is this not safe enough -- race of both signal handlers checking for
the signal_handling at the same time? What would be the right way to do
this generally? Thanks.
In this particular case, timeest is called fairly often, but simply
returns if not enough time elapsed since last report. I can make the
signal handler set the flag, which will make timeest report things the
next time it is called, even if 5 minutes did not elapse. This way,
signal handler will only deal with a variable assignment -- all of the
reporting (including proctitle update) will happen shortly afterwards --
on a normal stack.
-mi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
