From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r113437: New unwind-protect flavors to better type-check C callbacks. Date: Tue, 23 Jul 2013 10:00:53 +0100 Message-ID: <51EE4645.4000904@cs.ucla.edu> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1374570083 8012 80.91.229.3 (23 Jul 2013 09:01:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jul 2013 09:01:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 23 11:01:23 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V1YTD-0003KS-91 for ged-emacs-devel@m.gmane.org; Tue, 23 Jul 2013 11:01:23 +0200 Original-Received: from localhost ([::1]:43898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1YTC-0003Ij-Vh for ged-emacs-devel@m.gmane.org; Tue, 23 Jul 2013 05:01:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1YT6-0003Gq-23 for emacs-devel@gnu.org; Tue, 23 Jul 2013 05:01:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1YT1-0005XM-PR for emacs-devel@gnu.org; Tue, 23 Jul 2013 05:01:16 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:37787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1YT1-0005UZ-HY for emacs-devel@gnu.org; Tue, 23 Jul 2013 05:01:11 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 39333A60005; Tue, 23 Jul 2013 02:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuhiaqlPqwFL; Tue, 23 Jul 2013 02:01:01 -0700 (PDT) Original-Received: from [192.168.0.2] (host86-166-90-56.range86-166.btcentralplus.com [86.166.90.56]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 13409A60004; Tue, 23 Jul 2013 02:01:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162086 Archived-At: On 07/22/2013 05:13 AM, Stefan Monnier wrote: > I much preferred having a single record_unwind. The old way was simpler, but it had a problem: record_unbind_protect (foo, make_save_value (...)) didn't work when make_save_value exhausted memory and threw an error. To avoid the problem, there needs to be a way to invoke record_unwind_protect without the possibility of throwing an error before the protection is in place. record_unwind_protect_ptr does that, since the caller already can have a local variable in the C stack, and pass its address. This works because every function that calls record_unwind_protect_ptr also calls unbind_to to undo it, before returning. It wouldn't be feasible to convert all uses of record_unwind_protect to record_unwind_protect_ptr, because not every function that calls record_unbind_protect also calls unbind_to. Removing record_unwind_protect_int would not be trivial, since one can't simply replace it with record_unwind_protect + make_integer (as not all 'int' values fit into Lisp integers), and one can't simply replace it by passing an int * to record_unwind_protect_ptr (as not all functions that invoke record_unwind_protect_int also call unbind_to). We could trivially remove record_unwind_protect_void by using one of the other methods and passing a dummy argument. This would slow down execution very slightly, though. Plus, an advantage of having record_unwind_protect_void and record_unwind_protect_int is it catches more type errors at the C level. > No strong technical arguments for it (other than the fact that the > added SPECPDL_UNWIND_* cases in the switch slow down `unbind'). It shouldn't slow down 'unbind', at least on my x86-64 platform, since the switch is implemented as an indirect jump, which means that adding cases doesn't add any instructions for the existing cases. The new code should even speed up 'unbind' a tad, at least for the void case, since it can avoid passing an argument that the unwinder doesn't look at.