minhtrannhat/os161
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

New comments about thread allocation and deallocation.

Browse Source
This commit is contained in:
Geoffrey Challen 2016-03-05 09:35:55 -05:00
parent e19a872c2b
commit a7526befe4
1 changed files with 10 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
kern/thread/thread.c
View File

@ -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