I'll try to answer your questions, but I have only written a few sample pthread programs. But it's not like I'm a thread expert.
Quote:
Originally posted by DreamWarrior
I know that errno is thread safe when the _REENTRANT macro is defined...what about when it is not?
Then errno is not thread safe. If you insist on invoking a non thread safe library then your expected results are undefined. My guess is that the library will use the one-per-process errno and get the last error of any system call invoked by any thread. I would not expect repeatable results.
Quote:
Originally posted by DreamWarrior
2) I've seen functions re-written to be thread safe by doing their work in a local variable, then copying that local variable out to a user passed in storage area. What I wonder is, what about just using the user defined storage area directly?
When I've seen stuff like that, it was to warn against using a local static variable and then passing the address of that local static variable back to the caller. If you have a already written function that does that, a simple memcopy at the end will render it thread safe. I don't see a real problem in using the caller's area directly. But if you do that, you will be dereferencing a pointer, perhaps repeatedly. That may not be a speed win.
So they were not rewriten to USE a local variable. They were rewritten to not return a pointer to a local variable.
BTW, at very high optimization levels a memcpy will be "inlined", that is, it becomes a sequence of instructions rather than a true call. It may even become a single machine language instruction.
Quote:
Originally posted by DreamWarrior
Therefore, how do I provide both thread safe interfaces and standard interfaces in one library without requring an application to link with the pthread library.
Actually you have it backwards. Thread-safe interfaces are standard. A process is always a collection of threads. Sometimes it simply has one thread. You don't need a thread library unless you are assuming multiple threads, so don't assume that.
I haven't looked at the source code for the standard libraries, but I guess that there are 3 cases.
1. Some stuff is so primative that it always was thread safe.
2. Some stuff was not thread safe, but it could be made thread safe with changing the interface presented to the caller. So this was done.
3. Some stuff could not be made thread safe without visible changes. So seperate versions were made. For the most these are functions that tripped on the issue in your 2nd question.