Date: Fri, 18 Feb 2000 12:25:54 -0600 From: Alan Cox <alc@cs.rice.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@freebsd.org Subject: Re: tentitive complete patch for MAP_GUARDED available Message-ID: <20000218122554.A2978@nonpc.cs.rice.edu>
next in thread | raw e-mail | index | archive | help
> ... > Resource limits are still an issue. It turns out that the > MAP_STACK code does not deal with the stack resource limit > well at all -- sometimes it catches it, sometimes it doesn't. In what sense? My recollection is that resource limits are enforced on the "regular" process stack but not (except perhaps by accident of placement) on other stacks, such as those created by pthreads. At a higher level, it's not been obvious to me how the resource limit on stack size should be interpreted in a multithreaded program. In other words, I don't see one interpretation as obviously best, much less correct. At least three possibilies are: 1. It represents the maximum size of the "legacy" process stack and nothing else, which is what the code currently implements. (pthreads stacks are bounded by other means.) 2. It represents the maximum size of each and every stack, whether it's the "legacy" process stack or for example a pthreads stack. 3. It represents the sum of the size of all of the stacks. There are problems/drawbacks to each and every possibility. So, in conclusion, I think the first order of business is to determine what semantics (1) there may be good precedent for and (2) that threads programmers are comfortable with. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000218122554.A2978>