From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: request review: branch "wingo" Date: Mon, 30 Mar 2009 20:31:17 -0700 Message-ID: References: <874oxapu6c.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1238471190 26639 80.91.229.12 (31 Mar 2009 03:46:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2009 03:46:30 +0000 (UTC) Cc: guile-devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 31 05:47:48 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LoUx0-0002Xk-Rk for guile-devel@m.gmane.org; Tue, 31 Mar 2009 05:47:47 +0200 Original-Received: from localhost ([127.0.0.1]:55993 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LoUvd-0002Nd-9z for guile-devel@m.gmane.org; Mon, 30 Mar 2009 23:46:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LoUvW-0002NI-Or for guile-devel@gnu.org; Mon, 30 Mar 2009 23:46:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LoUvR-0002Mc-66 for guile-devel@gnu.org; Mon, 30 Mar 2009 23:46:13 -0400 Original-Received: from [199.232.76.173] (port=52257 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LoUvR-0002MZ-0a for guile-devel@gnu.org; Mon, 30 Mar 2009 23:46:09 -0400 Original-Received: from a-sasl-fastnet.sasl.smtp.pobox.com ([207.106.133.19]:43490 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LoUvQ-00041m-EO for guile-devel@gnu.org; Mon, 30 Mar 2009 23:46:08 -0400 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 1FDE3A6C55; Mon, 30 Mar 2009 23:46:07 -0400 (EDT) Original-Received: from unquote (unknown [75.84.114.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id CF65CA6C54; Mon, 30 Mar 2009 23:46:04 -0400 (EDT) In-Reply-To: <874oxapu6c.fsf@arudy.ossau.uklinux.net> (Neil Jerram's message of "Mon, 30 Mar 2009 22:39:07 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) X-Pobox-Relay-ID: 774E0078-1DA6-11DE-ABF1-32B0EBB1AA3C-02397024!a-sasl-fastnet.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8354 Archived-At: Hi Neil, Thanks for the review. On Mon 30 Mar 2009 14:39, Neil Jerram writes: > - add getrlimit and setrlimit wrappers > > Should scm_getrlimit code be surrounded by #ifdef HAVE_GETRLIMIT ? I think it is -- the same block includes the RLIM_*, the helper function, and the setrlimit definition. Not very clear though, I admit. > What's the idea of the numerical args? Should RLIMIT_XXX be defined > somewhere as Scheme-level integers? Uf, dunno. Now that I look at this again I'm not sure. We should probably just have RLIM_* and not the symbols, right? Easier for tab completion in any case... > Does it make sense to want to set the soft limit only? I thought some > hard limits were only settable by root, so I would suspect yes. If > yes, does the setrlimit implementation support this? You actually have to set both at the same time, in the system call interface. So if you want to just modify the soft limit, you have to first getrlimit to find the hard limit. Hard limits can only be decreased, not increased, and can be done so by the user process. This is good for e.g. before forking too. > - getrlimit-based stack limits > - rely on getrlimit to DTRT, don't make stack calibration file > > My inclination is that we should revert these; but I'm not sure, so > could be persuaded that I'm wrong. > > My feeling is that what we had before is a stronger statement (than > using getrlimit) about the expected behaviour of typical Scheme > programs (and in particular those used during the build), and is > therefore worth keeping. The getrlimit implementation just says "if a > program is running away, we'll generate a Scheme exception a little > bit before you'd otherwise get a core". I think that with the getrlimit code, we keep these guarantees, as much as we had them before. Before, you still didn't know that your program was not going to dump core, because when you were at 35000 words (say) and a C program recursed up to the limit without reentering Guile, you'd still dump core. (A contrived example.) What we have now is similar -- Guile's stack is set to 80% of the rlimit, or 1 MB, whichever is less. So in the worst case we have 20% of runway in which to prevent a segfault, and in the normal case (on my x86-32 laptop) we have 9 MB. It's actually a stronger guarantee, for example in the case in which your rlimit was set at 41000 words. > - fix "linking" of guile-config > > I don't understand the problem here. In what way was @bindir@ not > fully expanded? Because it was a make variable and not a shell variable, so it expanded to ${exec_prefix}/bin. (There was code in the Makefile.am before to sed in the variables at make-time instead of configure-time, but I had removed it to simplify things.) > - bugfix: don't dynamic link if we found a registered extension > > Would be great to have a test for this, if feasible. Done. >> I think the stack calibration stuff is correct, but perhaps more jarring >> in this commit is a move from ./pre-inst-guile to ./meta/guile, and >> ./pre-inst-guile-env to ./meta/uninstalled-env. I describe the rationale >> in 0b6d8fdc28ed8af56e93157179c305fef037e0a0. But then again, given that >> Neil invested so much time into the stack calibration stuff, that might >> be jarring too. > > As above - the meta/ stuff looks fine to me, but I'm not sure about > the stack limit change. I think that it gives us stronger guarantees and less hassle. Did my reasons sway your opinion at all? Andy -- http://wingolog.org/