From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,29850945228df59
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-06-17 09:07:20 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!skynet.be!skynet.be!louie!tlk!not-for-mail
Sender: lbrenta@lbrenta.corp.emc.com
Newsgroups: comp.lang.ada
Subject: Re: Boehm-Demers-Weiser conservative garbage collector and GNAT
References: <1316747.mXveBPtf0Z@linux1.krischik.com>
 <rw2wufl6po1.fsf@lbrenta.corp.emc.com>
 <slrnbetosb.8i1.randhol+abuse@kiuk0152.chembio.ntnu.no>
 <rw2of0x6m6j.fsf@lbrenta.corp.emc.com>
 <slrnbetrm0.atf.randhol+abuse@kiuk0152.chembio.ntnu.no>
 <rw2k7bk7web.fsf@lbrenta.corp.emc.com>
 <slrnbeu1ht.big.randhol+abuse@kiuk0152.chembio.ntnu.no>
 <Hazco47MvHdL@eisner.encompasserve.org>
 <slrnbeu47b.c8f.randhol+abuse@kiuk0152.chembio.ntnu.no>
 <rw27k7k7rgo.fsf@lbrenta.corp.emc.com>
 <QdZxXhgRp7Ti@eisner.encompasserve.orgOrganization: LJK Software
 <8nXPHPFBnkS2@eisner.encompasserve.org>
From: Ludovic Brenta <ludovic.brenta@insalien.org>
Date: 17 Jun 2003 18:08:35 +0200
Message-ID: <rw2u1ao4rgc.fsf@lbrenta.corp.emc.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
NNTP-Posting-Host: 213.190.149.159
X-Trace: 1055866039 reader0.news.skynet.be 298 fa058819/213.190.149.159:27971
X-Complaints-To: abuse@skynet.be
Xref: archiver1.google.com comp.lang.ada:39347
Date: 2003-06-17T18:08:35+02:00
List-Id: <comp.lang.ada>

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> The last major program I wrote was designed to minimize the amount
> of explicit memory allocation (using Ada83).  There were one or two
> chains of records that had to be cleaned up in between major groups
> of user commands.
> 
> There was a "lot" of stack-based memory used.

Interesting.  Did you encounter special difficulties designing your
program with this particular goal in mind?  Like for example
limitations on the size of the stack, or problems sharing objects
between threads?

-- 
Ludovic Brenta.