| > How exactly can a thread correctly die in such a way that frame of method that allocated the reply box on-stack is not cleaned up from it first? The thread could die incorrectly in that way. > Why the method even allocated shared data structure on its own stack Done for efficiency or when it's not desirable to have to check and recover from a failure to allocate such a structure. E.g. DECLARE_WAITQUEUE macro in Linux kernel: https://elixir.bootlin.com/linux/v4.3/source/include/linux/w... How blocking is implemented in Linux is that tasks declare wait queue nodes on the stack, register these into a queue, then change themselves to a sleep state and call the scheduler. > why would anyone consider thread which is actively waiting for something dead and try to reclaim its stack? What reclaims the stack isn't that "anyone"; it's garbage collection. It's plausible like this. Suppose the messaging API is responsible for dequeuing the waiter. The messaging API walks the queue, depositing replies into the reply boxes and dequeueing (without caring whether the associated threads are alive or dead). When it dequeues the dead thread's reply box, that stack then becomes unreachable. Now it is eligible for reclamation. |