multipath: clean up code for stopping the waiter threads
The way multipathd currently stops the waiter threads needs some work.
Right now they are stopped by being sent the SIGUSR1 signal. However their
cleanup code assumes that they are being cancelled, just like all the other
threads are. There's no reason for them to be so unnecessarily
complicated and different from the other threads
This patch does a couple of things. First, it removes the mutex from
the event_thread. This wasn't doing anything. It was designed to protect
the wp->mapname variable, which the waiter threads were checking to see
if they should quit. However, the mutex was only ever being used by the
thread itself, and it clearly didn't need to serialize with itself. Also,
the function to clear the mapname, signal_waiter(), was set with
pthread_cleanup_push(), which never got called early, since the threads
weren't being cancelled. Thus, the mapname never got cleared
until the pthreads were about to shut down.
The patch also rips out all the signal stopping code, and just uses
pthread_cancel. There already are cancellation points in the waiter
thread code. Between the cancellation points, both explicit and implicit,
and the fact that the waiter threads will never be killed except when the
killer is holding the vecs lock, there shouldn't be any place where the
waiter thread can access freed data.
To make sure the waiter thread cleans itself up properly, the dmt
has been moved into the event_thread structure, and is destroyed in
free_waiter() if necessary.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>