From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked] Date: Mon, 25 Jun 2007 05:30:14 -0400 Message-ID: <0B83D28B-95EF-4022-B447-63EA6BB3792E@raeburn.org> References: <467A4F49.9040906@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1182763843 30181 80.91.229.12 (25 Jun 2007 09:30:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 09:30:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 11:30:41 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I2ku8-0005yW-JU for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 11:30:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2ku7-00028S-Ve for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 05:30:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2ktj-0001zn-D0 for emacs-devel@gnu.org; Mon, 25 Jun 2007 05:30:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2kti-0001zU-QN for emacs-devel@gnu.org; Mon, 25 Jun 2007 05:30:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2kti-0001zQ-LM for emacs-devel@gnu.org; Mon, 25 Jun 2007 05:30:14 -0400 Original-Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I2kti-0006qx-AD for emacs-devel@gnu.org; Mon, 25 Jun 2007 05:30:14 -0400 Original-Received: from raeburn.org (c-65-96-188-63.hsd1.ma.comcast.net[65.96.188.63]) by comcast.net (rwcrmhc15) with ESMTP id <20070625093012m1500sq2efe>; Mon, 25 Jun 2007 09:30:13 +0000 Original-Received: from [69.25.196.101] (laptop.raeburn.org [69.25.196.101]) by raeburn.org (8.12.11/8.12.11) with ESMTP id l5P9UAbC017646; Mon, 25 Jun 2007 05:30:10 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.752.3) X-detected-kernel: NetCache Data OnTap 5.x X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73796 Archived-At: On Jun 25, 2007, at 04:30, YAMAMOTO Mitsuharu wrote: >> Nor is this change guaranteed to cause there to be only one access to >> "__malloc_hook", unless you change it to be declared volatile. (And, >> in fact, if you're optimizing, I would've expected it to be only one >> access in the original code on nearly all platforms.) > > As a matter of fact, the original code caused a real problem: > > http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-06/ > msg00170.html I'd believe it could be, sure. But if that code were produced with gcc -O2, I'd be disappointed. Other compilers ... eh, some of them aren't that good. :-) >> Mutex protection around accesses to the hook variable would be the >> safest (and wouldn't require temporary variables or volatile >> qualifiers), though performance would not be as good. > > Temporary variables will be necessary so that we can unlock the mutex > before the actual call to the hook. We also need to add some special > functions to change the hook variables and use them instead of > assignments to the hook variables in alloc.c. That's why I said that > "malloc in glibc 2.5 also does the same thing and I suspect that we > cannot do better as long as we try to keep the same interface with > respect to __malloc_hook etc." in > http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01503.html Yes, I think keeping the current glibc interface -- at least, as the one we actually use -- seems like a poor idea. Though the change should be coordinated with glibc maintainers, of course. Ken