On Sun, Oct 15, 2017 at 10:23:56AM -0400, John Ferlan wrote:
On 10/11/2017 10:52 AM, Erik Skultety wrote:
> Adjust udevEventHandleThread to be a proper thread routine running in an
> infinite loop handling devices. The handler thread pulls all available
> data from the udev monitor and only then waits until a wakeup signal for
> new incoming data has been emitted by udevEventHandleCallback.
>
This doing a bit more by removing the driver locks from initialization
too. Perhaps those locks should be kept on Initialization for now and
then in a followup patch remove them since @privateData (or whatever
name it becomes) is then totally self locking.
I don't think we'd run into any deadlocks since Initialization and
Cleanup would still be the only consumers.
Like I said, patch will be added.
[...]
> static bool
> @@ -1625,15 +1639,25 @@ udevPCITranslateDeinit(void)
> static int
> nodeStateCleanup(void)
> {
> + udevEventDataPtr priv = NULL;
> +
> if (!driver)
> return -1;
>
> + priv = driver->privateData;
> +
Although perhaps impossible, better safe than sorry
Here it's actually quite possible, when allocation of the private data in
Initialize fails, cleanup is performed, so this would get a SIGSEGV, thanks.
Erik
Perhaps we should keep it just for this patch and remove in the
"next"
patch leaving the goto unlock intact, but modifying it to be :
unlock:
if (priv)
virObjectUnlock(priv);
nodeDeviceUnlock();
Then the next patch alters the gots's and unlock: label to what this
patch has. It also removes nodeDeviceLock from Cleanup
Yeah, I'll handle the locking prior to adding this thread-related stuff.