[libvirt] [PATCH 04/11] Handle incoming data streams in libvirtd

[Daniel Veillard]

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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/