qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Handle G_IO_HUP in tcp_chr_read for tcp chardev


From: Kirill Batuzov
Subject: Re: [Qemu-devel] [PATCH] Handle G_IO_HUP in tcp_chr_read for tcp chardev
Date: Tue, 1 Jul 2014 17:54:18 +0400 (MSK)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Tue, 1 Jul 2014, Alex Bennée wrote:

> 
> Kirill Batuzov writes:
> 
> > Due to GLib limitations it is not possible to create several watches on one
> > channel on Windows hosts. See bug #338943 in GNOME bugzilla for details:
> > https://bugzilla.gnome.org/show_bug.cgi?id=338943
> >
> > Handle G_IO_HUP in tcp_chr_read. It is already watched by corresponding 
> > watch.
> > Also remove the second watch with its handler.
> >
> > This reverts commit cdaa86a54b232572bba594bf87a7416e527e460c.
> > ("Add G_IO_HUP handler for socket chardev") but keeps its functionality.
> <snip>
> > --- a/qemu-char.c
> > +++ b/qemu-char.c
> > @@ -2673,6 +2673,12 @@ static gboolean tcp_chr_read(GIOChannel *chan, 
> > GIOCondition cond, void *opaque)
> >      uint8_t buf[READ_BUF_LEN];
> >      int len, size;
> >  
> > +    if (cond & G_IO_HUP) {
> > +        /* connection closed */
> > +        tcp_chr_disconnect(chr);
> > +        return TRUE;
> > +    }
> 
> Is this right. AIUI we could return FALSE here to remove the watch for
> the now closed channel.
> 
>
tcp_chr_disconnect will remove the watch and perform other non-obvious
cleanup. Also we already have tcp_chr_disconnect followed by return TRUE
in tcp_chr_read:

    size = tcp_chr_recv(chr, (void *)buf, len);
    if (size == 0) {
        /* connection closed */
        tcp_chr_disconnect(chr);
    } else if (size > 0) {
            /* ... */
    }

    return TRUE;

Actually I'm not sure that tcp_chr_read handles all corner cases
correctly. For eaxmple, should not it be "size <= 0" instead of
"size == 0" in the above code? tcp_chr_recv may return negative value on error.
Should not tcp_chr_recv handle G_IO_ERR condition? It is watched in
corresponding watch.

But since we are in soft-freeze before 2.1 I decided to keep the patch as
simple as possible and not to fix theoretical bugs for which I do not
have real examples.

-- 
Kirill

reply via email to

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