errno-like variables in threaded environments

[Richard Tobin]

In a library I am writing, I want to use an errno-like mechanism
for error returns. The error would probably be represented as a
struct rather than just an integer.

I don't have any multi-threaded programs, but others may who want to
use my library. Most likely they'll be using a pthreads-compatible
threads system.

How can I best accommodate them? Presumably they will want the error
object to be in per-thread storage, so to set and retrieve it I should
provide functions or macros they can redefine. Ideally I'd like to be
able to build a single library (for each platform, using whatever
thread library is commonest there) that works with both threaded and
unthreaded applications, but I doubt that's possible.

-- Richard

 

[Toni Uusitalo]

I did some research on this "threads and errno" subject a while ago and
found this usenet thread (link might wrap a bit)

David Butenhorf's wrote in that thread for instance:

"As long as code doesn't
use the errno token in a manner that violates ANSI C, the thread-specific
errno token is transparent to the code."

here's the whole post (by David Butenhorf) and link to the thread too:

That depends on what threads you're using. If you're using POSIX threads
("pthread" prefixes), the interfaces are specified by the POSIX 1003.1-1996
(ISO/IEC 9945-1:1996) international standard. POSIX requires that each
thread must have a unique private errno value.

POSIX doesn't specify how this is to be accomplished, but the most common
mechanism is for the <errno.h> header, when compiled with proper thread
options (generally -D_REENTRANT), to define the token "errno" as a macro
that expands to something like "*(_errno())", where _errno() is a function
returning "int *". This allows you to use "if (errno)", or "x = errno", or
even "errno = x" just as you would normally.

Note that ANSI C 89 has always required that any code using the errno token
must have a #include <errno.h> in scope. POSIX 1003.1-1990 (an earlier
version of the POSIX standard that didn't include threads) "overrode" that
requirement, specifying that "traditional C" practice of using the errno
token with only "extern int errno;" in scope. POSIX 1003.1-1996 removed the
earlier override, falling back to the ANSI C rules. As long as code doesn't
use the errno token in a manner that violates ANSI C, the thread-specific
errno token is transparent to the code.

http://groups.google.fi/groups?hl=f...v=/groups?q=errno+%22thread+safe%22+windows%2
6hl%3Dfi%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D9gr1f5%2524alj%25241%254
0nntp9.atl.mindspring.net%26rnum%3D2&seekm=9gr1f5%24alj%241%40nntp9.atl.mind
spring.net

In a library I am writing, I want to use an errno-like mechanism
for error returns. The error would probably be represented as a
struct rather than just an integer.

I don't have any multi-threaded programs, but others may who want to
use my library. Most likely they'll be using a pthreads-compatible
threads system.

How can I best accommodate them? Presumably they will want the error
object to be in per-thread storage, so to set and retrieve it I should
provide functions or macros they can redefine. Ideally I'd like to be
able to build a single library (for each platform, using whatever
thread library is commonest there) that works with both threaded and
unthreaded applications, but I doubt that's possible.

-- Richard

with respect,
Toni Uusitalo

 

[Malcolm]

In a library I am writing, I want to use an errno-like mechanism
for error returns. The error would probably be represented as a
struct rather than just an integer.

You've got huge problems. ANSI C doesn't define any threading behaviour, but
typically threads will have their own stacks and share globals. What this
means is that it is very difficult to prevent the wrong thread getting hold
of an error set by another. What's worse is that the conflict won't happen
very often, so the program will be fine when you test it and then the bug
will show up just when you're least ready to deal with it, for example the
day before you ship.

One way is to pass a parameter to receive error data. This will uglify your
code but has the advantage of reminding the caller to check for failure.
Another way is to use another language that has error-handling mechanisms.
This is rather an extreme step to take.

 

[pete]

I did some research on this "threads and errno"
subject a while ago and
found this usenet thread (link might wrap a bit)

I think that the most important thing mentioned here,
is that there is such a newsgroup as:

 

[Richard Tobin]

I think that the most important thing mentioned here,
is that there is such a newsgroup as:
news:comp.programming.threads

Good point, I'll post a copy there.

-- Richard