From a7526befe4daa7ee9493fb5eeedecd01c17e7694 Mon Sep 17 00:00:00 2001 From: Geoffrey Challen Date: Sat, 5 Mar 2016 09:35:55 -0500 Subject: [PATCH] New comments about thread allocation and deallocation. --- kern/thread/thread.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/kern/thread/thread.c b/kern/thread/thread.c index d21388f..ae252e4 100644 --- a/kern/thread/thread.c +++ b/kern/thread/thread.c @@ -255,6 +255,9 @@ cpu_create(unsigned hardware_number) * Nor can it be called on a running thread. * * (Freeing the stack you're actually using to run is ... inadvisable.) + * + * Thread destroy should finish the process of cleaning up a thread started by + * thread_exit. */ static void @@ -263,11 +266,6 @@ thread_destroy(struct thread *thread) KASSERT(thread != curthread); KASSERT(thread->t_state != S_RUN); - /* - * If you add things to struct thread, be sure to clean them up - * either here or in thread_exit(). (And not both...) - */ - /* Thread subsystem fields */ KASSERT(thread->t_proc == NULL); if (thread->t_stack != NULL) { @@ -771,6 +769,13 @@ thread_startup(void (*entrypoint)(void *data1, unsigned long data2), * should be cleaned up right away. The rest has to wait until * thread_destroy is called from exorcise(). * + * Note that any dynamically-allocated structures that can vary in size from + * thread to thread should be cleaned up here, not in thread_destroy. This is + * because the last thread left on each core runs the idle loop and does not + * get cleaned up until new threads are created. Differences in the amount of + * memory used by different threads after thread_exit will make it look like + * your kernel in leaking memory and cause some of the test161 checks to fail. + * * Does not return. */ void