Re: [libvirt] [PATCH 04/11] Handle incoming data streams in libvirtd
On Mon, Aug 24, 2009 at 09:51:07PM +0100, Daniel P. Berrange wrote:
* qemud/stream.c: Handle incoming stream data packets, queuing until
stream becomes writable. Handle stream completion handshake
* po/POTFILES.in: Add qemud/stream.c
[...]
+/*
+ * Callback that gets invoked when a stream becomes writable/readable
+ */
+static void
+remoteStreamEvent(virStreamPtr st, int events, void *opaque)
+{
+ struct qemud_client *client = opaque;
+ struct qemud_client_stream *stream;
+
+ /* XXX sub-optimal - we really should be taking the server lock
+ * first, but we have no handle to the server object
+ * We're lucky to get away with it for now, due to this callback
+ * executing in the main thread, but this should really be fixed
+ */
+ virMutexLock(&client->lock);
Shouldn't the stream stucture carry a reference to the
connection/server ?
[...]
static int
-remoteStreamFilter(struct qemud_client *client ATTRIBUTE_UNUSED,
- struct qemud_client_message *msg ATTRIBUTE_UNUSED,
- void *opaque ATTRIBUTE_UNUSED)
+remoteStreamFilter(struct qemud_client *client,
+ struct qemud_client_message *msg, void *opaque)
{
+ struct qemud_client_stream *stream = opaque;
+
+ if (msg->hdr.serial == stream->serial &&
+ msg->hdr.proc == stream->procedure &&
+ msg->hdr.type == REMOTE_STREAM) {
+ DEBUG("Incoming rx=%p serial=%d proc=%d status=%d",
+ stream->rx, msg->hdr.proc, msg->hdr.serial, msg->hdr.status);
+
+ /* If there are queued packets, we need to queue all further
+ * messages, since they must be processed strictly in order.
+ * If there are no queued packets, then OK/ERROR messages
+ * should be processed immediately. Data packets are still
+ * queued to only be processed when the stream is marked as
+ * writable.
+ */
Since we are already separating different classes of packets, why not
extend this to provide 2-3 classes for the data too: BACKGROUND/NORMAL/URGENT
that can be added later using the current flags for creating a stream.
ACK, though this need much testing, ideally we can automate this in
TCK, especially about Abort effect at various point in time of a
transfer. This is hard to test by the application writer so we should
try to make the API as foolproof as prossible.
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/