From owner-freebsd-arch Tue Oct 9 6:27:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CADA537B409 for ; Tue, 9 Oct 2001 06:27:53 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA10775; Tue, 9 Oct 2001 15:27:43 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Bruce Evans Cc: Peter Wemm , Subject: Re: Removing ptrace(2)'s dependency on procfs(5) References: <20011009221951.B25192-100000@delplex.bde.org> From: Dag-Erling Smorgrav Date: 09 Oct 2001 15:27:42 +0200 In-Reply-To: <20011009221951.B25192-100000@delplex.bde.org> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans writes: > The correctness of not looping depends on nothing except the parent > making the process runnable (unless the process loses its P_TRACED > attribute). This is apparently what happens, since things have worked > for so long. But I don't completely understand what happens when a > signal is sent to the process. The comment before this section of > code suggests looping. ...but the code will never loop, because trace_req() always returns 1. What intrigues me further is that trace_req() used to always return 0, and the log entry for the commit that changed it does not explain why it changed to returning 1. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message