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)
        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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to