Patrick -
Thank you very much for the speedy reply to my message.
>>>You're asking "how to distinguish errno (global) from errno ( thread local) on OS X 10.5 Leopard?",
>>>but I don't think that question even makes any sense;
Ok, may be I was not too clear what I was looking for. Let me re-phrase and make the situation more specific....
1. there are 2 threads within application.
2. thread TH1 is coming to the point :
...
if((rst_wait=sem_wait(&sem)) < 0) // At this point, the thread is preempted and `sleeping`, waiting being waked-up
err_wait = errno;
}while ( (rst_wait <0) && ((err_wait == EINTR) || (err_wait == 9)));
...
3. second thread, TH2 is coming to the point:
...
if(fsync(aio.aio_fildes) < 0){ // For some reason, TH1 is waked-up while TH2 is executing fsync()....
lerror = (int)errno;
};
.....
sem_post(&sem); // TH1 is expected being waked-up at this point!
....
The behavior I'm observing - thread TH1 is waked-up while TH2 is within library call fsync(...);
In addition, the resulted errno - err_wait - is set up to EBADF ( 9), which is not even in the spec /manual for sem_wait(),
( but in the spec /manual for fsync()....).
(The expected behavior :
- later within the code, TH2 is calling sem_post(&sem). At this point, I'm expecting TH1 to be waken up.
( That is the behavior of the code on Linux machine).
OR
- the TH1 is waked up with the code ` [EINTR] The call was interrupted by a signal.`
)
Also, as soon as the err_wait became 9, the consequent calls to sem_wait() return immediately, with the same
err_wait == 9.
Consistence, which I can reproduce above with, makes me believe that TH1 is actually reading the `global` errno.
or errno, which was set/triggered by TH2.
I have found a few notes in this forum archives, saying that there were racing condition within
int * __error() function implementation itself... The behavior I'm observing - fitting `profile' of the reported bug....
But this bug was dated to ~2002, and it seems was not connected to current OS X release.
Also, I have found in the couple of books the references that libc implementation supports 2 copies of errno - one `global`, and one, which is `thread oriented/related`.
Basically, I'm a bit puzzled with above behavior of the code, and looking for work around and/or fix.
Any ideas will be highly appreciated. Once again, thanks for your attention to this matter.
Michael.
On Fri, Oct 3, 2008 at 7:40 PM, Patrick Rutkowski
<email@hidden> wrote:
Using the symbol "errno" is the right thing to do in all cases, threaded or non-threaded.
This is why it's usually implemented as a macro, so that under the hood it's really a call
to some OS specific function get the thread's local errno, e.g.:
./sys/errno.h:#define errno (*__error())
You're asking "how to distinguish errno (global) from errno ( thread local) on OS X 10.5 Leopard?",
but I don't think that question even makes any sense; there's no such thing as a global errno, as far
as I can tell.
-Patrick
On Oct 3, 2008, at 6:56 PM, Michael Andronov wrote:
Hi,
I am presently debugging an application, which has 2 threads:
1. First thread - TH1 - is waiting to be waked up within the function sem_wait(...)
2. Second thread - TH2 - is executing some code. Within such code, there is a call for fsync(...) function.
The behavior is that if fsync() function within TH2 is failing, then TH1 is returning form sem_wait(...) with errno EBADF ( int 9).
The only explanation I see is that for some reason global errno is checked within TH1 instead of thread local.
The code , in C++, is compiled with `-pthread` flag, under OS X 10.5...
My question is how to distinguish errno (global) from errno ( thread local) on OS X 10.5 Leopard?
Thanks for kind attention to this matter.
Michael.
P.S> I have seen same posting about similar issue dated 2002, but the `fixes` seems not working on 10.5...
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden