Vladimir Pouzanov <[email protected]> writes: > On Thu, Apr 24, 2014 at 9:01 AM, Ben Gamari <[email protected]> wrote: > >> Unfortunately this replaces the ugly possibility of unpredictable >> crashes with the slightly less ugly possiblity of unpredictable >> deadlocks if we run out of stack in the middle of execution. Perhaps >> threads could be annotated with their maximum expected stack size, >> allowing stack chunks to be allocated at spawn-time. >> > > It wouldn't be allowed to grow, it's exactly that — maximum expected stack > size, task either fits in there or dies. > Ahh, I see now.
For the record, my original interpretation of your suggestion was to maintain a pool of stack chunks, each new thread taking one chunk at spawn time. If a thread were to run out of stack, it would be allocated another chunk from the pool. If there were none left in the pool, it would be suspended until another thread frees up a chunk (which would happen on thread death and perhaps via a reclaim mechanism). While this scheme is arguably a bit more flexible it's not at all clear that this amount of fragile complexity is desirable here. I prefer the "you don't fit, you die" approach. You just need to ensure that the stack size is reasonable and that you have enough stacks for the maximum number of concurrent threads. Cheers, - Ben
pgpqA14hIhrOb.pgp
Description: PGP signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
