From owner-p4-projects Fri May 3 9:40:35 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id F1F2637B426; Fri, 3 May 2002 09:40:15 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 22F6837B404; Fri, 3 May 2002 09:40:07 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020503164007.CSMG4412.rwcrmhc52.attbi.com@InterJet.elischer.org>; Fri, 3 May 2002 16:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA83171; Fri, 3 May 2002 09:38:17 -0700 (PDT) Date: Fri, 3 May 2002 09:38:17 -0700 (PDT) From: Julian Elischer To: Jonathan Mini Cc: Perforce Change Reviews Subject: Re: PERFORCE change 10740 for review In-Reply-To: <20020503085009.C81190@stylus.haikugeek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Fri, 3 May 2002, Jonathan Mini wrote: > Julian Elischer [julian@elischer.org] wrote : > > > On Fri, 3 May 2002, Jonathan Mini wrote: > > 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. the constructor is thread_alloc and the destructor is thread_exit/thread_free (it takes 2 steps to exit a thread) also check out thread_reap(). I have no problem with calling it thread_alloc except that your reason was spurious. (the clash with "itself"). > > > > - 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()? > Umm MOST threads are allocated from either msleep or fork. remember in a threaded process you allocate and activate a new thread when the old one blocks (i.e. is in msleep()). So to answer your question.. this is about the most common case.. :-) > -- > 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