On Fri, Mar 15, 2013 at 10:50:08AM +0100, Viktor Mihajlovski wrote:
> On 03/15/2013 10:33 AM, Daniel P. Berrange wrote:
> >
> >No, this really isn't solving the problem. The virConnectDipose
> >function is the last thing to run on an object. Once virConnectDispose
> >is running absolutely nothing e
On 03/15/2013 10:33 AM, Daniel P. Berrange wrote:
No, this really isn't solving the problem. The virConnectDipose
function is the last thing to run on an object. Once virConnectDispose
is running absolutely nothing else may safely use that object pointer.
The thread that is not in virConnectDisp
On Thu, Mar 14, 2013 at 01:26:55PM +0100, Viktor Mihajlovski wrote:
> A race condition can occur when virConnectClose is called parallel
> to the execution of the connection close callback in remoteClientCloseFunc.
>
> The race happens if the connection object is destroyed (including
> the mutex)
On 03/15/2013 12:28 AM, Eric Blake wrote:
-if (conn->closeFreeCallback)
+if (conn->closeCallback)
+conn->closeCallback = NULL;
The if is pointless. Just blindly set conn->closeCallback to NULL.
agreed
+
+if (conn->closeFreeCallback) {
conn->closeFreeCallback(co
On 03/14/2013 06:26 AM, Viktor Mihajlovski wrote:
> A race condition can occur when virConnectClose is called parallel
> to the execution of the connection close callback in remoteClientCloseFunc.
>
> The race happens if the connection object is destroyed (including
> the mutex) while remoteClient
A race condition can occur when virConnectClose is called parallel
to the execution of the connection close callback in remoteClientCloseFunc.
The race happens if the connection object is destroyed (including
the mutex) while remoteClientCloseFunc is waiting for the connection
mutex. After the des
