From owner-cvs-all@FreeBSD.ORG Wed Dec 20 19:44:12 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C89616A4D0; Wed, 20 Dec 2006 19:44:12 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id E52F943D73; Wed, 20 Dec 2006 19:43:37 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id kBKJgmft040645; Wed, 20 Dec 2006 20:42:49 +0100 (CET) (envelope-from mb@imp.ch) Date: Wed, 20 Dec 2006 20:42:48 +0100 (CET) From: Martin Blapp To: Attilio Rao In-Reply-To: <3bbf2fe10612200816x11c59af3r8b1d2721215267fe@mail.gmail.com> Message-ID: <20061220202842.E53548@godot.imp.ch> References: <200612192234.kBJMYYo0055529@repoman.freebsd.org> <3bbf2fe10612191850y3a546fcew486575385b1400df@mail.gmail.com> <20061220040337.H53548@godot.imp.ch> <3bbf2fe10612200816x11c59af3r8b1d2721215267fe@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.58 on 157.161.9.65 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern tty.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 19:44:12 -0000 Hi, >Ok, after a quick look at the patch (and this note) it makes more >sense to me, but then would not be cleaner to do something like: > > sx_slock(&proctree_lock); > if (tp->t_session && tp->t_session->s_leader) { ... > } > sx_sunlock(&proctree_lock); > You mean to restore rev. 1.258 ? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/tty.c.diff?r1=1.257&r2=1.258 The answer is easy, rev. 1.258 costs more in the cases where tp->t_session is already empty and we don't need to add a proctree lock and can just continue. We need the proctree lock only if tp->t_session exists. You can call rev. 1.267 less invasive than rev. 1.258 :-) -- Martin