Date: Fri, 3 May 2002 08:50:09 -0700 From: Jonathan Mini <mini@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 10740 for review Message-ID: <20020503085009.C81190@stylus.haikugeek.com> In-Reply-To: <Pine.BSF.4.21.0205030807030.82741-100000@InterJet.elischer.org>; from julian@elischer.org on Fri, May 03, 2002 at 08:12:31AM -0700 References: <200205031451.g43Epu600512@freefall.freebsd.org> <Pine.BSF.4.21.0205030807030.82741-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mini@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020503085009.C81190>