Date: Wed, 5 Sep 2001 09:21:25 -0400 (EDT) From: Mikhail Teterin <mi@aldan.algebra.com> To: bde@zeta.org.au Cc: tlambert2@mindspring.com, asmodai@wxs.nl, current@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: proctitle progress reporting for dump(8) Message-ID: <200109051321.f85DLSo63141@aldan.algebra.com> In-Reply-To: <20010905201754.U22592-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109051321.f85DLSo63141>