On Thu, Jan 15, 2009 at 05:23:33PM +0000, Richard W.M. Jones wrote:
On Tue, Jan 13, 2009 at 05:44:00PM +0000, Daniel P. Berrange wrote:
> The 'xm' driver currently keeps all its state in a global static
> variables. Not cool, since we access this from all sorts of places
> and its hard to guarentee thread safety. So we move the state into
> the virConnect object. This will increase memory usage if a single
> process has multiple Xen connections open though.
>
> Undecided whether this is a big problem or not. If so, I'll can
> try and redo the next thread locking patch to use a lock over the
> existing global state.
>
> xen_inotify.c | 4
> xen_unified.c | 1
> xen_unified.h | 14 ++-
> xm_internal.c | 262 +++++++++++++++++++++++++++++-----------------------------
> xm_internal.h | 3
> 5 files changed, 149 insertions(+), 135 deletions(-)
The patch appears straightforward enough, and for the XM driver
(ie. ancient history Xen) I'm sure we don't care much about a tiny bit
of extra memory.
I don't care about the memory usage at this point, I'm more concerned
about inserting bugs in that code. Looks a relatively mechanical change
and it's probably safer than something based on locking.
+1
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/