Date: Wed, 12 Dec 2001 14:52:09 -0800 From: Julian Elischer <julian@vicor-nb.com> To: arch@freebsd.org Subject: Threads, KSEs etc. during exit. Message-ID: <3C17DF99.1DE9D1A1@vicor-nb.com>
next in thread | raw e-mail | index | archive | help
Here is an implimentation detail I've hit that I'd like to discuss because it has some ramifications for non KSE code too. During the life of a threaded process, (and even a non threaded process during exit) the kernel's thread structures are are created and freed whenever there is a change in the number of threads active in a process. (where userland counts as one activation, and each sleeping or active syscall counts as one). WHen a thread becomes surplus to requirements, the final acts it makes would be to call thread_free() (new call) and cpu_throw() (existing). thread_free would call the current pmap_dispose_thread(td); and zfree(thread_zone, td); This is all ok except that pmap_dispose_thread(td) will free the stack pages so are we safe in returning? No. In the current world, the stack is not freed until the wait() system call (maybe much) later in the context of another process. So the race is avoided because thread stacks are only freed as part of process teardown. This makes the ZOMBIE actually hold a lot more resources that one might imagine. (specifically several pages of kernel stack it will never use, and a full u-area). Ideally I'd like to discard the thread structure and it's stack when the last cpu_throw() is called to make the zombie smaller, (as above) (If I could think of a way around the race above), but even if I don't I still hit the same race whenever a kernel thread is declared surplus to requirements, and something else is to be run. One answer would be to make whatever thread is selected next actually do the freeing of the previously running (now zombie) thread, but this increases the complexity of the switch routine. Another would be to switch the context of the dying thread to a per processor dummy thread/stack before the cpu_throw() is called and let the dummy context free the original. Basically what I need is: come in with a context from a "doomed" thread. leave in the context of a thread from the run queue, with the doomed thread now in the free list (of threads) with its resources (e.g. stack) freed too. It's not impossible but I'd like to know what others who have been around that code think is the best answer. (I am working in the KSE kernel to make threads NOT a part of the proc structure.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C17DF99.1DE9D1A1>