This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- From: Ian Lance Taylor <iant at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Roland McGrath <roland at hack dot frob dot com>, Richard Henderson <rth at twiddle dot net>, GNU C Library <libc-alpha at sourceware dot org>, Andrew Hunter <ahh at google dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Fri, 20 Sep 2013 14:19:32 -0700
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <20120612193224 dot 8E43619060E at elbrus2 dot mtv dot corp dot google dot com> <4FD8D974 dot 7090903 at twiddle dot net> <20120613182826 dot 0CFAB2C0A3 at topped-with-meat dot com> <CALoOobMtXCw+oe7ZL0=my8YH5st8b1==CasS8i07z6G9DfaX-w at mail dot gmail dot com> <20120613210444 dot 659732C095 at topped-with-meat dot com> <mcr4nqebzok dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <20120614002931 dot ABB762C08B at topped-with-meat dot com> <mcr1uliaeep dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <CALoOobPJ7G7ciRfc2JwzHjsDTg4-_h-SXqeU1zR4WEzoyQhyNg at mail dot gmail dot com> <523BD470 dot 6090203 at redhat dot com> <CAKOQZ8y85QBkd97cEEmP-4OgE2KizCqknrVR_n44pwBGMs5uAw at mail dot gmail dot com> <523C88D1 dot 6090304 at redhat dot com> <CAKOQZ8ze1zKdQRsMsmBCqnJr361Gvv8mYjLjGgzYwWJEKUY+7w at mail dot gmail dot com> <523CB72A dot 7040507 at redhat dot com>
On Fri, Sep 20, 2013 at 1:59 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/20/2013 01:56 PM, Ian Lance Taylor wrote:
>>> * Work with the community to ensure consensus around an
>>> acceptable solution.
>>
>> To be clear, Google already has a patch, as Paul mentioned in the
>> message that restarted this thread. And frankly I thought this idea
>> was a slam dunk if it could be implemented, and I'm surprised to see
>> so much resistance. At this point I have to say that the community
>> does not seem interested, so my inclination would be to skip it and
>> just do something that works internally. That is disappointing but it
>> is quite possible that I am missing something about this issue.
>
> I'm disappointed that after a couple of email exchanges you appear to
> be about to call it quits.
>
> As far as I can tell we're having a good discussion around some points
> that I raised.
>
> What you're missing is that not everyone agrees with you, and that
> glibc is a consensus driven community. We don't want one Overlord that
> accepts patches from Google and checks them in as they see fit.
Obviously I don't think that. I've been doing free software for
decades for many companies. I wasn't saying "we're Google and you
should take our patch." I was saying "this is a real problem, and
there is an existing patch, and you should work with that patch, or
rewrite it, to get it in."
> All I can say is that if you stick around we'll see it through to
> some kind of solution.
Thanks, I'm glad to hear it. That is not the message I took away from
your earlier e-mail messages, which to me sounded like a set of
reasons not to fix this problem.
Paul said: we have a patch and asked "Is this something that has a
chance of being acceptable into trunk?" I expected the answer to that
question to be "Yes, there is a good chance." I did not expect the
answer to be "Being lazy and dumb I don't want to maintain a complex
TLS implementation, and being dumb means I can't."
Ian