* a question about the implementation of errno
@ 2018-07-04 5:07 lihuiba
2018-07-04 10:35 ` Florian Weimer
0 siblings, 1 reply; 3+ messages in thread
From: lihuiba @ 2018-07-04 5:07 UTC (permalink / raw)
To: libc-help
Hi all,
I noticed recently that errno is implemented as a macro that expands to (*__errno_location()).
I wonder why it is implemented as this, and why it is not a thread-local int variable.
I suppose thread-local int is faster than function all.
Thanks!
Huiba Li
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: a question about the implementation of errno
2018-07-04 5:07 a question about the implementation of errno lihuiba
@ 2018-07-04 10:35 ` Florian Weimer
2018-07-04 11:34 ` lihuiba
0 siblings, 1 reply; 3+ messages in thread
From: Florian Weimer @ 2018-07-04 10:35 UTC (permalink / raw)
To: lihuiba, libc-help
On 07/04/2018 07:07 AM, lihuiba wrote:
> I noticed recently that errno is implemented as a macro that expands to (*__errno_location()).
> I wonder why it is implemented as this, and why it is not a thread-local int variable.
> I suppose thread-local int is faster than function all.
Thread-local errno was added when the library (and the dynamic linker)
did not support proper TLS variables.
We haven't changed it because it is not clear that it is a win. On some
platforms, the instruction sequence to call __errno_location and then
load the value from the returned pointer is actually *shorter* than a
TLS variable access. Since access to errno happens mostly on error
paths (where performance isn't a concern, in general), we expect that
the shorter instruction sequence preferable here.
Thanks,
Florian
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re:Re: a question about the implementation of errno
2018-07-04 10:35 ` Florian Weimer
@ 2018-07-04 11:34 ` lihuiba
0 siblings, 0 replies; 3+ messages in thread
From: lihuiba @ 2018-07-04 11:34 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-help
Shorter instruction sequence on error path is a good reason.
Thank you, very much!
At 2018-07-04 18:34:59, "Florian Weimer" <fweimer@redhat.com> wrote:
>On 07/04/2018 07:07 AM, lihuiba wrote:
>
>> I noticed recently that errno is implemented as a macro that expands to (*__errno_location()).
>> I wonder why it is implemented as this, and why it is not a thread-local int variable.
>> I suppose thread-local int is faster than function all.
>
>Thread-local errno was added when the library (and the dynamic linker)
>did not support proper TLS variables.
>
>We haven't changed it because it is not clear that it is a win. On some
>platforms, the instruction sequence to call __errno_location and then
>load the value from the returned pointer is actually *shorter* than a
>TLS variable access. Since access to errno happens mostly on error
>paths (where performance isn't a concern, in general), we expect that
>the shorter instruction sequence preferable here.
>
>Thanks,
>Florian
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-07-04 11:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-04 5:07 a question about the implementation of errno lihuiba
2018-07-04 10:35 ` Florian Weimer
2018-07-04 11:34 ` lihuiba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).