`errno' (Dan Pop)

  • Thread starter Vijay Kumar R Zanvar
  • Start date
V

Vijay Kumar R Zanvar

In said:
Your analysis is correct. You cannot even declare errno, because it can
be (and quite often is) defined as a macro in <errno.h>. The common
reason for this is allowing multithreaded applications to have a per
thread errno, rather than sharing a global errno. This is one of the
few places where the C standard cares about multithreading.

[Today I happened to see that this mail was hiding in the "Drafts" folder
for more than a month!]

I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.
 
C

Christian Bau

"Vijay Kumar R Zanvar said:
I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.

If "errno" were a plain extern variable, then all threads in a
multithreading application would always see the same "errno" variable.
So if thread A calls a function which might change errno, then checks
errno immediately after the function call, then another thread B could
be calling a different function modifying errno just before thread A
reads the value of errno. So thread A might read the wrong value.

In multithreading applications, you usually have a modified standard
library where every thread has its own "errno" variable, and a library
function called by thread X modifies the errno variable belonging to
thread X. Usually errno is a macro defined as a function call returning
the errno variable of the current thread.
 
K

Keith Thompson

Vijay Kumar R Zanvar said:
I am at loss as how defining `errno' as a macro can be helpful in
multithreading applications. Please enlighten me.

Assume each thread has its own data area. The hypothetical __errno()
function returns a pointer into the data area of the current thread.
This way, each thread effectively gets its own unique errno variable.
 
V

Vijay Kumar R Zanvar

Christian Bau said:
If "errno" were a plain extern variable, then all threads in a
multithreading application would always see the same "errno" variable.
So if thread A calls a function which might change errno, then checks
errno immediately after the function call, then another thread B could
be calling a different function modifying errno just before thread A
reads the value of errno. So thread A might read the wrong value.

In multithreading applications, you usually have a modified standard
library where every thread has its own "errno" variable, and a library
function called by thread X modifies the errno variable belonging to
thread X. Usually errno is a macro defined as a function call returning
the errno variable of the current thread.

Nicely explained. Thanks.
 
V

Vijay Kumar R Zanvar

Keith Thompson said:
Assume each thread has its own data area. The hypothetical __errno()
function returns a pointer into the data area of the current thread.
This way, each thread effectively gets its own unique errno variable.

This paragraph clears my doubt. Thanks.
 
T

those who know me have no need of my name

in comp.lang.c i read:
If "errno" were a plain extern variable, then all threads in a
multithreading application would always see the same "errno" variable.

this is not required or always true (think platform magic). but it's off-
topic so i'll not go into it further.
 
D

Dan Pop

In said:
in comp.lang.c i read:
this is not required or always true (think platform magic).

Of course it is required and always true. Once implementation magic gets
involved, errno is no longer "a plain extern variable".

Dan
 
R

Richard Tobin

Of course it is required and always true. Once implementation magic gets
involved, errno is no longer "a plain extern variable".

I think by "if errno were a plain extern variable" the poster meant
"if errno's declaration were a plain extern variable declaration", in
contrast to being declared as a macro. At least, that reading is one
that makes his comment comprehensible.

-- Richard
 
X

Xenos

Of course it is required and always true. Once implementation magic gets
involved, errno is no longer "a plain extern variable".
I can be. On the environment I work on, it is. Its value is swapped during
a context switch along with the registers.

DrX
 
D

Dan Pop

I can be. On the environment I work on, it is. Its value is swapped during
a context switch along with the registers.

This is another way to say that each context has its own errno, which is
perfectly natural and doesn't require any compiler magic. However, a
context switch and a thread switch are not the same thing.

Dan
 
D

Dan Pop

In said:
I think by "if errno were a plain extern variable" the poster meant
"if errno's declaration were a plain extern variable declaration", in
contrast to being declared as a macro. At least, that reading is one
that makes his comment comprehensible.

I doubt many implementors would bother making implementation magic work
for ordinarily declared identifiers. It's far more sensible to put the
implementation magic in the declaration of the identifier, like:

extern __thread_local int errno;

in which case errno is no longer a plain extern variable.

Dan
 
X

Xenos

Dan Pop said:
This is another way to say that each context has its own errno, which is
perfectly natural and doesn't require any compiler magic. However, a
context switch and a thread switch are not the same thing.

Dan
That's just arguing sematics. A thread switch is a context switch, though
there are other kinds of context switches.

DrX
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top