From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed, 19 May 2010 09:56:15 -0400
To: 9fans@9fans.net
Message-ID: <45a0bc53c25d3f197697043a26824244@kw.quanstro.net>
In-Reply-To: <8a7d369bb212b77cb4ca5c8b1408a267@plan9.bell-labs.com>
References: <8a7d369bb212b77cb4ca5c8b1408a267@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] thread STACK size
Topicbox-Message-UUID: 270a6ee0-ead6-11e9-9d60-3106f5b1d025

> As a general rule in threaded programs, avoid declaring local arrays
> or large structs.  Instead, malloc them and free them when you're done.
> A file server, as an example, should never allocate an 8K message
> buffer on the stack.  If you can manage to obey the rule of not having
> arrays on the stack (as local variables), you can usually comfortably
> make use of 4K or 8K stacks.

i've always followed this rule myself.  but it just occurs to me that
there might be another way of looking at this.

if our mythical program needs a fixed-size message buffer for every
request, there are advantages to the stack.  dynamic allocation
with the pool library is slow and single-threaded.  and of course,
any dynamic allocation is more work and can be fatal.

- erik