From owner-p4-projects Fri May 3 8:46:22 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 3A8C737B41C; Fri, 3 May 2002 08:46:16 -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 B6C1F37B41B for ; Fri, 3 May 2002 08:46:14 -0700 (PDT) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id B9463A900; Fri, 3 May 2002 08:50:09 -0700 (PDT) Date: Fri, 3 May 2002 08:50:09 -0700 From: Jonathan Mini To: Julian Elischer Cc: Perforce Change Reviews Subject: Re: PERFORCE change 10740 for review Message-ID: <20020503085009.C81190@stylus.haikugeek.com> References: <200205031451.g43Epu600512@freefall.freebsd.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: ; from julian@elischer.org on Fri, May 03, 2002 at 08:12:31AM -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 : > 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.... Oho! Well, then. =) I see what was going on now. I misread the code and though that p_xxthread was a pointer. =) I can change the code back, no problem, but I still feel that thread_alloc() is a more appropriate name (caching allocators are really quite common). Also, after some discussion between me and jhb on #bsdcode, it became clear that we'd want a struct thread ctor/dtor pair that'd help with things like fork and exit. His suggestion was a thread_alloc()/thread_exit() pair. I haven't really looked into it in detail, so I'm not sure yet. > > - 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.. Hmm. Why would you allocate a thread from within msleep()? -- 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