a question about the implementation of errno

a question about the implementation of errno

[lihuiba]

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

Re: a question about the implementation of errno

[Florian Weimer]

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

Re:Re: a question about the implementation of errno

[lihuiba]

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