[asterisk-dev] Re: Pthread wrapper updates

[SF Markus Elfring]

> That's not quite true in this case.  At the Asterisk developer's conference
> in Italy this Summer, we made a decision that there was no reason we
> should be checking the return value of ast_mutex_lock.
This is interesting background information.

> The reason that was given at this time was that since we use recursive
> mutexes everywhere, there was no reason we needed to check if it was successful.
>   
This kind of reasoning looks strange to me.

> Furthermore, on the topic of this thread, I can't imagine *any* case
> where if we detect some type of error, that aborting the application
> is the right thing to do.
I say that the program execution can not continue to correctly run after 
a lock or unlock operation failed because an absolutely required 
resource could not be acquired or released. Which reactions would you 
expect if a similarly important operation like a memory allocation does 
not succeed?

> We should always write our code in such a way that we try to deal
> with problems and recover from them, and not intentionally make things
> worse by aborting the entire application.
How would you try to recover from "unexpected" return values like 
EINVAL, EBUSY or EDEADLK?

Would you like to look at 
"http://groups.google.de/group/comp.programming.threads/tree/browse_frm/thread/bd013d03610120d2/9989672acf27e396" 
for usual advices?

Regards,
Markus