On 13 April 2016 at 22:03, Dongwon Kim <[email protected]> wrote: > There are four different places where the program pointer may jump to > 'cleanup:' while the mutex is still possilby being locked. Two > of those cases are when mtx_lock(pthread_mutex_lock) fails to lock > the mutex. However, this can't be a problem because the mutex is either > not in "locked" state because current thread fails to acquire it or > even if it's locked, it's owned by another thread. > > The other two places are when mtx_unlock call fails to unlock the mutex. > This is also not a problem. According to manpage, pthread_mutex_unlock > only can return EINVAL or EPERM. EINVAL means the mutex is not > initialized. But if it's uninialized, the code should have already > failed while trying to acquiring it. EPERM is also not an issue > because this error code means current thread doesn't own the mutex. > In other words, the function is not responsible for unlocking it. > All of these will disappear if we drop checking the return value of mtx_{un,}lock, right ?
Iirc it was one of the suggestions mentioned alongside the "the function does not return TRUE/FALSE" one ;-) -Emil _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
