On Thu, Oct 05, 2017 at 02:54:36PM +0200, Erik Skultety wrote:
[...]
> > + while (1) {
> > + virMutexLock(&privateData->lock);
> > + while (privateData->nevents == 0 &&
!privateData->threadQuit) {
> > + if (virCondWait(&privateData->threadCond,
&privateData->lock)) {
> > + virReportSystemError(errno, "%s",
> > + _("handler failed to wait on
condition"));
>
> Is a virMutexUnlock required before eventually calling virMutexDestroy...
It is, but even an unlock wouldn't be enough, since there's concurrent access,
even if everything goes smooth, the handle callback could be already waiting in
queue to lock the mutex, which is too an undefined behaviour. So I'll change it
so that the thread doesn't do any thread-local data cleanup (except for mutex
unlock) and I'm going to add the free callback to virEventAddHandle, so that the
data will be freed eventually.
Aand of course ^this is wrong since someone might be holding the lock during
the time we try to remove the handle or the thread might be simply waiting for
the kernel (its ultimate purpose) and the next time it touches the mutex, well,
not good, so that wouldn't fly either. I have to give it more thought,'
especially how and when the thread is decommissioned.
Erik