Daniel P. Berrange wrote:
The current test driver keeps all its state in memory and is not thread safe. Since background jobs will need to access state from a thread periodically we need to make the test driver thread safe. This is done with 2 levels of locking - A global driver lock. - A per-connection lock Before taking the per-connection lock, the global driver lock must be acquired. The driver lock can be released the moment the connection lock is acquired. The connection lock must be held for the duration of all driver methods which are accessing the 'struct testConn' or 'struct testDom' or 'struct testNet' data. To keep this reasonably unobtrusive, the GET_CONNECT, and GET_DOMAIN / GET_NETWORK macros have been altered to do the neccessary lock acquisition. The RELEASE_DOMAIN and RELEASE_NETWORL macros are new, and must be used prior to returning from any driver method so that mutex are released. This is a fairly coarse level of locking, but effective enough for the test driver which is not performance critical - merely safety critical. This model should apply reasonably safely to the QEMU driver too, though we may wish to make it finer grained.
Sensible. Maybe add some artifically slow functions to the test driver as well so that we can test job control?
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list