[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Re: emacs-22.1 with GTK dumps core when Gnome wigets

From: YAMAMOTO Mitsuharu
Subject: Re: address@hidden: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
Date: Mon, 25 Jun 2007 17:30:53 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.1.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Mon, 25 Jun 2007 01:33:59 -0400, Ken Raeburn <address@hidden> said:

>> !   /* Copy the value of __malloc_hook to an automatic variable in  
>> case
>> !      __malloc_hook is modified in another thread between its
>> !      NULL-check and the use.  */
>> !   hook = __malloc_hook;
>> !   return (hook != NULL ? *hook : _malloc_internal) (size);
>> }
>> Assignment is not guaranteed to be atomic.  It probably is on 32- 
>> bit systems, but you should not assume it.

> 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:


> 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

                                     YAMAMOTO Mitsuharu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]