Why do threads keep their stack when terminated and not disconnected?

Question

When you use streams and the stream runs to completion, but has not been disconnected, it is in a zombie state, waiting for it to be connected or disconnected so that its resources can be cleared.

I read that two of the “resources” that are not cleared when the thread is a zombie are a stack and a return value.

Can someone tell me the logic allowing the stack to persist until a connection is made? If there is a separate place for the return value, I cannot come up with a good reason - but I am sure that there is one, and I would like to know it when I use streams.

Answer 1

The technical implementation of saving life on the stack is simpler. Implementing your threads can use the bottom of the stack as a workspace even to unregister the current thread from the scheduler. Subsequently, the thread invocation context join() can be used to remove the space.

If you delete the stack before join() - that is, in the context of the terminating thread - you will not have a stack or other memory for a short time between deleting the stack and unregistering the stream.

Answer 2

Whether the stack returns as soon as the thread exits depends on the OS.

The following stream is well read: link .

I find the following post by Roger Faulkner quite interesting:

At least in Solaris 9 and 10, the thread threads that the library allocated (using mmap ()) are freed up for reuse immediately after the thread termination. A thread structure containing the thread ID and return value is not freed until pthread_join () (or pthread_detach ()).

For quick reuse for a new cache, a cache of up to 10 threads is stored. Old stacks outside the cache - munmap () d.

On my Ubuntu system, the stack is not restored until pthread_join() is called. I suspect this is just an implementation artifact, not a conscious design decision.