From owner-cvs-all@FreeBSD.ORG Thu Mar 16 14:13:03 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ECFA16A420; Thu, 16 Mar 2006 14:13:03 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE27543D55; Thu, 16 Mar 2006 14:12:53 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from localhost.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2GECqOA078689; Thu, 16 Mar 2006 14:12:53 GMT (envelope-from davidxu@freebsd.org) From: David Xu To: John Baldwin Date: Thu, 16 Mar 2006 22:12:47 +0800 User-Agent: KMail/1.8.2 References: <200603140400.k2E40LiR095530@repoman.freebsd.org> <200603161208.25942.davidxu@freebsd.org> <200603160834.06672.jhb@freebsd.org> In-Reply-To: <200603160834.06672.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603162212.47412.davidxu@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_exit.c kern_thread.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: Thu, 16 Mar 2006 14:13:03 -0000 On Thursday 16 March 2006 21:34, John Baldwin wrote: > I'm not sure why setrunqueue() of some other thread X != curthread > would care about the state of curthread since it should bail out of > preemption checking as soon as it sees that curthread is in a critical > section. > The problem is that you have unregistered current thread from scheduler, but still call setrunqueue, this may cause lots of scheduler code to be involved in, AFAIK, it is the deepest code path in both schedulers, whether it works or not is totally dependent on how a scheduler is designed, it may or may not have interesting to check current thread's attributes. at least, I would like to avoid such risk. > In any case, you can always move the function call in question down > further below the proc unlock. One change I had in my patches was > to stick the PROC_UNLOCK() after the big if-statement so there was > just one of them instead of doing it at the end of each case in the > if-else. > This branch code was written by julian, I don't have any idea whether it is good or bad, but I can understand that he might had prepared to handle different cases, but simply there was nothing to do in else case, I really don't care this style, some books even suggest programmer to always write a else branch for if statement. :-) David Xu