From owner-freebsd-arch  Wed Sep  5  6:23: 2 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1DAAF37B408; Wed,  5 Sep 2001 06:22:49 -0700 (PDT)
Received: from aldan.algebra.com (localhost [127.0.0.1])
	by aldan.algebra.com (8.11.5/8.11.5) with ESMTP id f85DLSo63141;
	Wed, 5 Sep 2001 09:21:32 -0400 (EDT)
	(envelope-from mi@aldan.algebra.com)
Message-Id: <200109051321.f85DLSo63141@aldan.algebra.com>
Date: Wed, 5 Sep 2001 09:21:25 -0400 (EDT)
From: Mikhail Teterin <mi@aldan.algebra.com>
Subject: Re: proctitle progress reporting for dump(8)
To: bde@zeta.org.au
Cc: tlambert2@mindspring.com, asmodai@wxs.nl, current@FreeBSD.ORG,
	arch@FreeBSD.ORG
In-Reply-To: <20010905201754.U22592-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

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-arch" in the body of the message