I was running into a problem where the evt api appeared to be getting into a

deadlock situtation. The problem would occur when I would kill aisexec
while my program was running (using EVT and CLM apis). My program is
multi-threaded where 1 thread is calling evtDispatch and other threads
can be calling evtPublish at various times. The problem I ran into is when I
killed aisexec, the evtDispatch would take a lock, but never give it back.
At the same time, my sending thread would call evtPublish which would take
the lock and hang since evtDispatch never gave up the lock it took.

The fix was to add a few unlocks in evt.c where they appeared to be missing.
Here is the info:

1) line 504 in evt.c (lib dir) calls

pthread_mutex_unlock(&evti->ei_mutex);
goto error_unlock;

2) There are subsequent calls to goto error_unlock in later error statements
that do not unlock the mutex before the goto call - the lines are 534 and 541

Adding the unlock right before the goto @ 534 and @ 541 fixes the deadlock
for my scenario.

Kristen Smith
Nortel Networks

(Logical change 1.110)


git-svn-id: http://svn.fedorahosted.org/svn/corosync/trunk@394 fd59a12c-fef9-0310-b244-a6a79926bd2f

lib/evt.c

@@ -531,6 +531,7 @@ saEvtDispatch(
 			error = saRecvRetry(evti->ei_fd, &dispatch_data->header,
 				sizeof(struct res_header), MSG_WAITALL | MSG_NOSIGNAL);
 			if (error != SA_OK) {
+				pthread_mutex_unlock(&evti->ei_mutex);
 				goto error_unlock;
 			}
 			if (dispatch_data->header.size > sizeof(struct res_header)) {
@@ -538,6 +539,7 @@ saEvtDispatch(
 					dispatch_data->header.size - sizeof(struct res_header),
 					MSG_WAITALL | MSG_NOSIGNAL);
 				if (error != SA_OK) {
+					pthread_mutex_unlock(&evti->ei_mutex);
 					goto error_unlock;
 				}
 			}