This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Async signal safe TLS accesses

On Thu, Nov 28, 2013 at 11:26:03PM -0500, Carlos O'Donell wrote:
> On 11/28/2013 11:01 PM, Rich Felker wrote:
> > On Fri, Nov 29, 2013 at 04:55:48AM +0100, OndÅej BÃlka wrote:
> >> A proper solution would be make generic malloc async-signal safe. It is 
> >> question of what is acceptable overhead. I can make a wrapper over any
> >> allocator that does that at cost of two tls access. You would pay a mmap
> >> overhead only when you are in signal where we do not care about
> >> effectivity.
> > 
> > Not a solution as long as glibc officially supports applications
> > replacing malloc.
Third party issue, signal safety is beyond of what is mandated by
standards and on best effort. Ask a custom allocator to implement signal
safety or use appropriate wrapper.
> The loader could access the implementation's malloc via GLIBC_PRIVATE
> symbols.
or different name than malloc, or creating interceptor library that has
priority over user allocator by prepending it to LD_PRELOAD in linker or
> I'm against this because any sufficiently complex and performant 
> implementation of malloc will be difficult to audit for AS-safety.
What I send is a wrapper, it is irrelevant how complex and convoluted
allocator is, it just suffices to check that wrapper correctly
intercepts calls and detect signal behaviour. 

> In the end AS-safety may even limit your flexibility, but I don't
> discount the possibility of writing the allocator such that it performs
> well.
Not on x86, I did a benchmark to see how big is overhead, after
eliminating sources of noise a signal safe variant is pretty
indistingushible from normal. There were two preventable slowdowns,
first was that dynamic tls is access slower so we need to use static tls.
Second was caused by gcc which emmited storing five registers at start
of free for unlikely code for returning memory that is suppressed by
appropriate expect.

> A small signal-safe allocator as proposed by Google is the easiest way
> to get the job done. We can always fix this later.
We are talking about two separate changes. One is replacing locks by
atoimics, second is using safe allocator. There are several
possibilities how implement allocator, so we should move discussion to
separate thread.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]