On Wed, Dec 03, 2008 at 09:44:50AM +0000, Daniel P. Berrange wrote:
On Wed, Dec 03, 2008 at 10:32:58AM +0100, Daniel Veillard wrote:
On Sun, Nov 30, 2008 at 11:55:51PM +0000, Daniel P. Berrange wrote:
This patch makes the network driver thread safe, following the pattern of the earlier patches
@@ -95,6 +107,7 @@ networkAutostartConfigs(struct network_d unsigned int i;
Hum, you're not locking the driver itself during the loop ? If a concurrent call were to remove one of the network object in the meantime, that would lead to potentially random memory accesses no ?
There are only two callers of this method, and they both already hold the driver lock - networkStartup() and networkReload().
I realized that when digging more in the storage case... see next mail :-)
cleanup: + if (network) + virNetworkObjUnlock(network);
like for domain, I would suggest the unlocking accessor to accept NULL and drop all the if constructs
I've thought about doing that, but wasn't really sure whether it was good idea or not. I thought it might hide bugs, but on balance it would certainly simplify alot of code. If people generally think its worth allowing NULL in the Unlock routine, i'll make it so.
well we did a similar change for freeing ... Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/