From owner-p4-projects Fri May 3 8:36: 9 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 6FEF437B404; Fri, 3 May 2002 08:35:59 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by hub.freebsd.org (Postfix) with ESMTP id 87B1437B41B for ; Fri, 3 May 2002 08:35:36 -0700 (PDT) Received: (qmail 6989 invoked from network); 3 May 2002 15:35:35 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 May 2002 15:35:35 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g43FZYF11903; Fri, 3 May 2002 11:35:34 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 03 May 2002 11:35:27 -0400 (EDT) From: John Baldwin To: Julian Elischer Subject: Re: PERFORCE change 10740 for review Cc: Perforce Change Reviews Cc: Perforce Change Reviews , Jonathan Mini 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 On 03-May-2002 Julian Elischer wrote: > > > On Fri, 3 May 2002, Jonathan Mini wrote: > >> http://people.freebsd.org/~peter/p4db/chv.cgi?CH=10740 >> >> Change 10740 by mini@mini_stylus on 2002/05/03 07:51:09 >> >> - Change thread_get(void) -> thread_alloc(void) to keep from >> conflicting with thread_get(struct proc *) in sys/kerne/kern_proc.c. > > but, but but... the thread_get() in kern_proc.c is a standin for the > one in kern_thread.c whe there is no kern_thread.c > > they are supposed to be the same function.. teh one in kern_proc.c > is removed when kse is added..... > > I called it thread_get rather than thread_alloc because > it caches them and doesn always need to allocate a new one.... We already have a slab allocator for that, no need to reinvent it. >> - uma_zalloc(,M_WAITOK) will never return NULL, so don't bother >> testing for it. > > You may be right, but I wasn't convinced that M_WAITOK was always > correct. I was trying to concieve af a case where you may not ba able to > wait when trying ot allocate a new thread.. > for example if you are trying to allocate it when you are already in > msleep().. it may be bad to sleep when in msleep already... > I think I may have other ways to stop this but think about it and > check the anti-recursion code in msleep(). > It may be that M_NOWAIT is the right answer.. This in fork1(). I think a better way of avoiding this is to have each KSE have a spare thread it can use when a thread blocks. The first action a spare thread when it starts up is to allocate a new spare thread if needed. However, I think you should only have one spare thread per-KSE and not a list. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message