[Asterisk-Dev] lock.h change on 10-28 (rev 1.39) means you can never use pthread_mutex_t?

Kevin P. Fleming kpfleming at digium.com
Wed Nov 2 12:16:17 MST 2005


steve at daviesfam.org wrote:

> Nevertheless, I do feel this change is rather a curve-ball to send down so
> late in the 1.2 process.  5 minutes before beta2 is shipped this is
> changed; my Sirrix-using users start to grab it, and ... oops ... compile
> errors.  Steve?  Sirrix?  Don't you even test that your code compiles?

I understand; sorry for that. I was just trying to clean things up and 
make them consistent for the release. To be honest, the previous version 
of all this stuff was _supposed_ to complain if you used the 
pthread_mutex_* functions directly, but it did not always do so. The new 
version _always_ does so.

> I don't think every pthread_ call is masked by an ast_ equivalent.  For 
> instance pthread_setcanceltype() - are calls like this in danger of being 
> masked out in the future?

Only the ones that operate on mutexes and conditions; the rest of them 
we don't provide wrappers for because we don't have 'debugging' versions 
of them to deal with. It's possible we could do that in the future, 
though, if we decide to start using more objects provided by the 
pthreads library and add debugging wrappers around them.



More information about the asterisk-dev mailing list