Re: [9fans] Plan 9 stack limit?

[erik quanstrom <quanstro@quanstro.net>]

On Tue Sep  6 19:10:46 EDT 2011, mathieu.lonjaret@gmail.com wrote:
> maybe slightly relevant:
> http://9fans.net/archive/2010/05/446
> (see also answers from others as well afterwards).
> 
> On Wed, Sep 7, 2011 at 12:30 AM, Comeau At9Fans <comeauat9fans@gmail.com> wrote:
> > I have an application that is crashing on Plan 9.  Now, it could be a bug in
> > the code, but in the past, similar problems with the same code base on other
> > platforms have always been caused by the system stack being blown out, and
> > in a less rare case, the systems running out of process space.  The crashes
> > are happening on 9vx.OSX (which is currently the only place it can be tested
> > on our systems).   Does 9vx have any such limitations and/or does Plan 9 in
> > general have any such limits?  And if so, can they be changed?   I see some
> > of the threading calls have stack size requests possible, but don't see any
> > such concerns as a consequence of a fork, though I'm sure fork is
> > semantically equivalent to some other calls when all is said and done.
> > Like I said, it could be a bug in the code, but I'd like to approach it from
> > this level first assuming there is any such interaction that even exists so
> > any insights would be appreciated.

good reference.

it's worth noting that a gsoc student (venkatesh srinivas) extended the plan 9
segment model to allow an arbitrary number of them.  this was fairly interesting,
but not of much practical interest.  then he implemented the concept of "segment
group".  group segments alter the address space of each process in the group.
then (here's the neat part) the thread library was modified to make two adjacent
group segments for each stack.  the lower one is not mapped and will always fault
on reference.  the upper one is grow-down, zero-and-map on reference,
so there's not much penalty for making your thread stacks a little too large.
the main limit is deference to machines with a punny 32-bit address space.

i really need to take another look at this and see about merging it into my kernel.
thread library stacks are a big debugging hassle.

- erik