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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Ian Lance Taylor <iant at google 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: Sun, 22 Sep 2013 13:54:32 -0400
- 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> <CAKOQZ8z=GtQSs_N1ej9EFJaifCEBm4X-u1nCgmjN-Q_gMubQcA at mail dot gmail dot com>
On 09/20/2013 05:19 PM, Ian Lance Taylor wrote:
>> 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.
If that's not the message you took away then I apologize for being unclear.
My previous email was intended to be a list of all the things I think we
need to consider and answer to end up with a high quality implementation.
As part of the technical discussion you can feel free to disagree or
disregard all or some of the points on my list.
> 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."
That was a tongue and cheek response to your point about being lazy.
I'm trying to be as honest as possible with you, and I felt it
dishonest to say "Yes, there is a good chance." without ever having
seen the code for the implementation.
Are we interested in fixing things? Yes.
Would we like to fix TLS use in signals? Yes.
Is there a chance that it gets accepted into trunk? It depends.
Next step: Post code. Review. Iterate.
Cheers,
Carlos.