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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list