This is the mail archive of the libc-alpha@sourceware.org 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 09/23/2013 07:14 PM, Andrew Hunter wrote:
> Some notes on this patch and the preceding discussion:

I'm still reviewing the patch, but I wanted to respond to this quickly.

> - I tested this patch on 2.15; I have rebased it to HEAD here but not
> heavily tested it (since it seems we can't make any progress here
> without seeing the code in question anyway.)  It certainly builds.  If
> I screwed up something in the rebase, please don't throw rotten fruit
> at me.

I will assume that you've run `make -k check' and nothing regressed
which is the minimum required, please correct me if I'm wrong.
 
> - I have made my best guesses as to a few questions of upstream
> preferences (see in particular the comment in dl_mask_signals.) I am
> happy to do pretty much anything roughly equivalent that you would
> prefer.

That's fine, I'll comment on that in the patch. FWIW I think your
solution is fine.
 
> As to the questions of the long-term allocator:
> 
> This patch defines signal_safe_malloc and friends as weak symbols in
> ld.so.  My expectation is that libc itself will override them with
> smarter definitions.  (If so, we can probably replace the current
> ld.so implementation with the "normal" symbols in dl-minimal, as I
> believe during ld.so bootstrap there's no opportunity to take signals.
>  I wasn't 100% sure of that so I went with the current approach for
> now.)

As a first pass we are not going to make this API public, nor allow
anyone to override it.

Designing a public API is much more work and requires more discussion,
including what's best practice, is the malloc API appropriate for this
case, could we do anything better, etc. etc.

We'll mark the symbols private and use them only in ld.so or from
libc.so, but they will still be internal and private.

We will solve the problem at hand which is to make TLS variables safe
for access from async-signal handlers.

It's a distinct problem to provide an API for signal-safe allocation
of memory (which I also assume you want to be thread-safe, but not
necessarily async-cancel safe).

Remember that we are a conservative project because once we release
an API we try to support it forever. While we may have made mistakes
in the past it doesn't preclude use from reaching for this goal :-)

> I do not care what you end up going with for the design of the smarter
> allocator in libc itself: the nice thing about this setup is that
> anyone, say me, can override with smart signal_safe_malloc
> definitions, and for our internal use this is precisely what I plan to
> do.  I am happy to go with whatever anyone else feels like as a libc
> signal_safe_malloc.  But if you were to ask me, this is what I would
> do:

I agree that providing and overridable signal-safe allocator in libc
is useful, it's not the first step in getting this into glibc.

> Define signal_safe_* in malloc/.  Have them use the dlmalloc machinery
> of arenas (though not call malloc() directly.)  In the current
> implemenation, I believe this can be made safe pretty easily (the
> primary problem with current libc malloc is that it unconditionally
> locks the TSD-cached arena; that would have to be a trylock.)  The
> disadvantage is, as Carlos points out, that puts you on the hook to
> make sure dlmalloc _continues_ to be amenable to signal safety.
> However, it doesn't stop anyone from changing __libc_malloc without
> breaking signal_safe_malloc; in addition, there's no concern about
> people who override libc malloc, as they will only replace the malloc
> symbol, not signal_safe_malloc; since signal_safe_malloc will not call
> into tcmalloc or jemalloc or whatever they specify, this will work
> fine.
> 
> Thoughts?

Sounds like a great design. Certainly step 2 after step 1 though.

Comments?

Cheers,
Carlos.


Cheers,
Carlos.


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