[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