From mint-bounce@lists.fishpool.fi Thu Feb 19 14:44:59 2009 From: Eero Tamminen Organization: Koti To: mint@lists.fishpool.fi Subject: Re: [MiNT] Default Stack Size Date: Thu, 19 Feb 2009 21:39:59 +0200 User-Agent: KMail/1.9.9 Cc: Vincent =?iso-8859-1?q?Rivi=E8re?= , mint References: <499C82B4.6060005@atari-source.org> <499D3373.4090308@freesbee.fr> In-Reply-To: <499D3373.4090308@freesbee.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200902192139.59580.oak@helsinkinet.fi> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: oak@helsinkinet.fi Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id n1JJix97015753 Hi, On Thursday 19 February 2009, Vincent Rivière wrote: > > Therefore the only viable solution is to build dynamically expanding > > stack capabilities into the kernel. > > A dynamically expanding stack cannot be implemented without Virtual > Memory. So as long as Virtual Memory is not available in the FreeMiNT > kernel, the only solution is to use a fixed stack size for each process, > which is inherently insane as you have demonstrated. For threads Linux actually uses fixed sized stack (in latest kernels 8MB), but with virtual memory it of course gets physically allocated only when it's written to. - Eero PS. On one device I saw a program that crashed when running out of address space (2GB) because it leaking thread resources (stacks) by not joining threads it had created as joinable. We found this after wondering how the program could produce 2GB core dumps in a device that has only 128MB RAM and no swap... :-)