----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-openlmi.rhcloud.com/r/1274/#review1739 -----------------------------------------------------------

Ship it!

Ship It!

- Radek Novacek

On Nov. 20, 2013, 5:13 p.m., Tomáš Bžatek wrote:

---

This is an automatically generated e-mail. To reply, visit: http://reviewboard-openlmi.rhcloud.com/r/1274/

---

(Updated Nov. 20, 2013, 5:13 p.m.)

Review request for OpenLMI Developers.

Repository: openlmi-providers

Description

indmanager: Forcefully recreate mutexes on indication stop

Creating mutexes with the PTHREAD_MUTEX_ERRORCHECK attribute proved to be a wrong way. It turned out locking was not working properly as any attempt to lock already locked mutex failed with a return value that we didn't check. The only reason we were using this special attribute was to prevent crash on forcefully unlocking mutex in an unknown state. That didn't work either as long as EPERM was returned when trying to unlock the mutex that has been locked from other thread... that was forcefully canceled. That only led to deadlocks fortunately hard to hit, unfortunately equally hard to debug.

-- This should hopefully fix the deadlock issues we're seeing in buildbot.

Diffs

src/indmanager/ind_manager.h 383f4b65532453e2066a8f2123a0896e17646c07 src/indmanager/ind_manager.c 186f4da1db714d402a2bfe46bf1d302409b853a3

Diff: http://reviewboard-openlmi.rhcloud.com/r/1274/diff/

Testing

Thanks,

Tomáš Bžatek