Date: Sun, 14 Sep 1997 22:01:30 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: thorpej@nas.nasa.gov Cc: dyson@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: What is wrong with this snipet? Message-ID: <199709142201.PAA23603@usr09.primenet.com> In-Reply-To: <199709141716.KAA05915@lestat.nas.nasa.gov> from "Jason Thorpe" at Sep 14, 97 10:16:45 am
next in thread | previous in thread | raw e-mail | index | archive | help
> My work on an rfork(2) for NetBSD originally was to support user threads. > However, a few thing made me change my mind on that (one of them is > signal delivery semantics, another is lack of sane way to give the new > thread its own stack). Because of these (and other annoyances), it was > decided that rfork(2) wasn't the right way to do this, and I punted on the > idea of exporting an rfork(2) system call, especially since RFMEM as Plan 9 > works isn't particularly useful for threads, and it seems lame to implement > RFMEM differently from Plan 9 and still call it RFMEM :-) Heh. POSIX threading mandates the user supply the stack. This is a good idea because... er, uh, er... OK, it sucks! ;-). You can get user stacks by taking a page (no pun intended) from the paper on statistical memory protection. What you do is mmap pages from /dev/zero int an unused area way high in memory, with a large enough gap between the areas to accomondate stack growth. You start with only one page mapped. Then you trap the signal generated by references to stack pages following your mapped stack pages -- effectively, there are guard pages following yuor stacks -- and map more pages in, in the signal handler, as they are referenced. Voila! Auto-growing threads stacks in a single address space. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709142201.PAA23603>