Question

When you’re using threads, and a thread runs to termination, but was not detached, it is in a zombie state, waiting to be reaped with a join or to be detached so that its resources can be cleaned up.

I read that two of the ‘resources’ that are not cleaned up when a thread is a zombie are the stack and the return value.

Can someone tell me the logic for allowing the stack to persist until a join is made? If there is a separate location for the return value I cannot think of a good reason – but I’m sure there is one and I’d like to know it for when I use threads.

Answer 1

The technical implementation of keeping the stack alive is easier. Your threads implementation can use the bottom of the stack as working space even for unregistering the current thread from the scheduler. Afterwards, the context of the thread calling join() can be used to delete the space.

If you would delete the stack before join() – that is, in the context of the terminating thread – you would have no stack or other memory for the short time between the stack deletion and the thread unregistering.