From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.devel Subject: Re: port initialization? Date: Sat, 10 Aug 2002 09:12:37 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02081009123711.05101@locke.free-expression.org> References: <15693.15724.416839.636665@blauw.xs4all.nl> <0208081820210Z.05101@locke.free-expression.org> <877kiy7s8v.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1028988983 14217 127.0.0.1 (10 Aug 2002 14:16:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 10 Aug 2002 14:16:23 +0000 (UTC) Cc: hanwen@cs.uu.nl, guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17dX2U-0003hC-00 for ; Sat, 10 Aug 2002 16:16:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17dX3D-0000AL-00; Sat, 10 Aug 2002 10:17:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17dX2j-00007s-00 for guile-devel@gnu.org; Sat, 10 Aug 2002 10:16:37 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17dX2D-00006F-00 for guile-devel@gnu.org; Sat, 10 Aug 2002 10:16:36 -0400 Original-Received: from rockridge.uits.indiana.edu ([129.79.1.74]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17dX2D-00005z-00 for guile-devel@gnu.org; Sat, 10 Aug 2002 10:16:05 -0400 Original-Received: from fontz.uits.indiana.edu (fontz.uits.indiana.edu [129.79.1.76]) by rockridge.uits.indiana.edu (8.12.1/8.12.1/IUPO) with ESMTP id g7AEFtQJ001303; Sat, 10 Aug 2002 09:15:55 -0500 (EST) Original-Received: from locke.free-expression.org (dial-122-140.dial.indiana.edu [156.56.122.140]) by fontz.uits.indiana.edu (8.12.1/8.12.1/IUPO) with SMTP id g7AEFrhM013147; Sat, 10 Aug 2002 09:15:54 -0500 (EST) Original-To: Marius Vollmer X-Mailer: KMail [version 1.2] In-Reply-To: <877kiy7s8v.fsf@zagadka.ping.de> Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1056 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1056 On Saturday 10 August 2002 08:33, Marius Vollmer wrote: > Lynn Winebarger writes: > > > If you're running out of memory, you might be in a deeply > > recursed procedure that hasn't set any global variables, > > so when it aborts, many megabytes become garbage. It's > > not that unusual. > > Yes, but for throwing the error, we will also need some fresh storage, > I think. We could arrange things so that aborting will always work, > but I'm afraid that would be quite tricky, and for little gain on a > Unix-like OS. Might be different for embedded systems. Will it take more than some small fixed amount? It's not a sin to reserve a few words to deal with such situations. A related question is, what happens when you're low on memory and send an interrupt signal? Will the debugger (be able to) come up? Alternatively, to invoke the debugger when it bombs out by keeping some memory in reserve (make a switch for it). I suspect guaranteeing that would require not only a decent call/cc implementation but a way to give the garbage collector a new chunk of memory to handle (sort of call/cc on the gc). Probably too much work, but it might help writers of such silly algorithms see the error of their ways. Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel