From owner-freebsd-current  Fri Feb 18 10:26: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from cs.rice.edu (cs.rice.edu [128.42.1.30])
	by hub.freebsd.org (Postfix) with ESMTP id 3009537B9A4
	for <current@freebsd.org>; Fri, 18 Feb 2000 10:26:02 -0800 (PST)
	(envelope-from alc@cs.rice.edu)
Received: from nonpc.cs.rice.edu (nonpc.cs.rice.edu [128.42.1.219])
	by cs.rice.edu (8.9.0/8.9.0) with ESMTP id MAA13046;
	Fri, 18 Feb 2000 12:25:54 -0600 (CST)
Received: (from alc@localhost) by nonpc.cs.rice.edu (8.9.3/8.7.3) id MAA03001; Fri, 18 Feb 2000 12:25:54 -0600 (CST)
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> ...
>    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