Re: errno global vx. errno pthread...
Re: errno global vx. errno pthread...
- Subject: Re: errno global vx. errno pthread...
- From: "Michael Andronov" <email@hidden>
- Date: Sat, 4 Oct 2008 11:42:55 -0400
Terry -
1. I've double checked the code.
Within the below line of code:
err_wait = errno;
the errno is actually the macro from /usr/include/sys/errno.h -
`#define errno (*__error())`
To this end, I think the header file is included, unless we are
talking about different files.
2. Also, I looking further into the issue, I have noticed that though
the fsync() call ( see code below)
if(fsync(aio.aio_fildes) < 0){ // For some reason, TH1 is
waked-up while TH2 is executing fsync()....
lerror = (int)errno;
};
is waking up the TH1, fsync(...) itself is returning with no
fault... So, my original statement that fsync (...) produces EBADF (9)
may be not correct. ( Unless the fault is reported to the wrong thread
- TH1, rather then TH2)...
3. Tracing assembly code showed the following:
after the EBADF(9) appeared within TH1, the following calls of
sem_wait(&sem)
are translated into some syscall, which returning 9 in %rax
register, and then cerror call...
That is all findings for now. Thanks for the attention. I hope above
will provide some clue and helps to answer the question.
Michael.
On Sat, Oct 4, 2008 at 1:57 AM, Terry Lambert <email@hidden> wrote:
>
> You are looking at the global errno because you have not got the macro errno in scope because you have not included the appropriate header files for your application.
>
> -- Terry
>
> On Oct 3, 2008, at 6:05 PM, Michael Andronov wrote:
>>
>> 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 :
>> ...
>> do{
>> 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
>>
>> _______________________________________________
>> 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
_______________________________________________
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