All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kirill Batuzov <batuzovk@ispras.ru>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Antonios Motakis <a.motakis@virtualopensystems.com>,
	Nikita Belov <zodiac@ispras.ru>,
	qemu-devel@nongnu.org,
	Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
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)	[thread overview]
Message-ID: <alpine.DEB.2.02.1407011740380.4254@bulbul.intra.ispras.ru> (raw)
In-Reply-To: <87ionhp5ku.fsf@linaro.org>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1938 bytes --]

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	other threads:[~2014-07-01 13:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140527120423.15172.36698.stgit@3820>
2014-07-01 11:52 ` [Qemu-devel] [PATCH] Handle G_IO_HUP in tcp_chr_read for tcp chardev Kirill Batuzov
2014-07-01 12:04   ` Paolo Bonzini
2014-07-01 12:37     ` Michael S. Tsirkin
2014-07-01 12:41   ` Michael S. Tsirkin
2014-07-01 13:29   ` Alex Bennée
2014-07-01 13:54     ` Kirill Batuzov [this message]
2014-07-07 18:41   ` Nikolay Nikolaev
2014-07-08 10:18     ` Kirill Batuzov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1407011740380.4254@bulbul.intra.ispras.ru \
    --to=batuzovk@ispras.ru \
    --cc=a.motakis@virtualopensystems.com \
    --cc=alex.bennee@linaro.org \
    --cc=mst@redhat.com \
    --cc=n.nikolaev@virtualopensystems.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zodiac@ispras.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.