Date: Mon, 25 Nov 2002 13:19:47 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: "cvs-all@FreeBSD.org" <cvs-all@FreeBSD.org>, "cvs-committers@FreeBSD.org" <cvs-committers@FreeBSD.org>, Maxime Henrion <mux@FreeBSD.org>, David Xu <davidxu@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern kern_thread.c src/sys/sys proc.h sr Message-ID: <XFMail.20021125131947.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0211230027320.13569-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Nov-2002 Julian Elischer wrote: > > > On Sat, 23 Nov 2002, David Xu wrote: > >> This commit cause kernel panic when run threaded program. >> try /usr/src/tools/KSE/ksetest > > Maxime.. > > The extended PCB fields need to be freed for every > thread_exit(), not just when we eventually free the thread_structure > (which may never happen) Well, cpu_exit() isn't called for every thread_exit() so that isn't going to work, and cpu_thread_exit() is too early/late. In fact, anywhere in thread_exit() is really too early/late. So when is the case that it breaks, when a thread structure gets recycled? Perhaps it is the bit where we free the spare thread and make this thread the spare thread? Ugh. Hmm, why not use a per-cpu thread pointer that you put the curthread into and then have fork_exit() and mi_switch() check for a thread in that pointer and stick it in the zombie thread list if it finds one? Then the thread will get free()'d. With this you wouldn't bother with free'ing the current spare thread. -- John Baldwin <jhb@FreeBSD.org> <>< 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 cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20021125131947.jhb>