From owner-p4-projects Thu May 16 21:42: 2 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 30C6037B40B; Thu, 16 May 2002 21:41:56 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from 12-234-96-171.client.attbi.com (12-234-96-171.client.attbi.com [12.234.96.171]) by hub.freebsd.org (Postfix) with ESMTP id 48AD637B406 for ; Thu, 16 May 2002 21:41:55 -0700 (PDT) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id 3A929A900; Thu, 16 May 2002 21:41:47 -0700 (PDT) Date: Thu, 16 May 2002 21:41:47 -0700 From: Jonathan Mini To: Julian Elischer Cc: Perforce Change Reviews Subject: Re: PERFORCE change 11120 for review Message-ID: <20020516214147.B25907@stylus.haikugeek.com> References: <200205101530.g4AFUn510685@freefall.freebsd.org> <3CDC2BB5.366A7BF0@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CDC2BB5.366A7BF0@elischer.org>; from julian@elischer.org on Fri, May 10, 2002 at 01:21:09PM -0700 Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer [julian@elischer.org] wrote : > > + /* Reassign this thread's KSE. */ > > + if (ke != NULL) { > > + ke->ke_thread = NULL; > > WHOA! just because ke == td->td_kse doesn't mean that > ke->ke_thread == td > > UNLESS you can guarantee that thread unlink is always run with td == curthread > or td->td_state == TDS_RUNNING. thread_unlink() (quoted above) is only called from thread_exit(). thread_exit() exits the currently scheduled thread, so td == curthread and td->td_state == TDS_RUNNING. We're safe both ways. > > + p->p_numthreads--; > > what of the kg->kg_numthreads.. Ten lines down, is : > > + if (kg != NULL) > > + kg->kg_numthreads--; > > move this up? To before the proc is unlinked? Why? > plus other comments already noted by others.. > (tabbing and sleeping with locks) The tabbing is fixed. As for sleeping with locks in UMA functions, Jeff said that it is ok to sleep for a short time, but long-term sleeps aren't such a good idea (makes sense). The only problem he foresaw was that the init/fini functions could be called by the pager daemon, but I don't see any problem there either. Somebody, please correct me if I'm wrong. -- Jonathan Mini http://www.haikugeek.com "He who is not aware of his ignorance will be only misled by his knowledge." -- Richard Whatley To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message