[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait'

From: Paul Brook
Subject: Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
Date: Wed, 8 Apr 2009 21:39:05 +0000
User-agent: KMail/1.9.9

> It has to be some finite amount.   You're right, it's arbitrary, but so
> is every other memory limitation we have in QEMU.  You could make it
> user configurable but that's just punting the problem.
> You have to do some level of buffering.  It's unavoidable.  If you
> aren't buffering at the event level, you buffer at the socket level, etc.

No you don't. If you use event flags rather than discrete events then you 
don't need to buffer at all. You just need to be able to store the state of 
each type of event you're going to raise, which should be a bounded set.

This has its own set of issues - typically race conditions or "lost" events if 
the client (libvirt) code isn't written carefully, and means you can't attach 
information with an event, only indicate that something happened.
However if the correct model is used (event driven polling rather than purely 
event driven) this shouldn't be problem.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]