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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
