[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 08/45] Return path: socket_writev_buffer: Blo
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH v5 08/45] Return path: socket_writev_buffer: Block even on non-blocking fd's |
Date: |
Wed, 11 Mar 2015 12:51:57 +1100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Tue, Mar 10, 2015 at 01:35:58PM +0000, Dr. David Alan Gilbert wrote:
> * David Gibson (address@hidden) wrote:
> > On Wed, Feb 25, 2015 at 04:51:31PM +0000, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert" <address@hidden>
> > >
> > > The return path uses a non-blocking fd so as not to block waiting
> > > for the (possibly broken) destination to finish returning a message,
> > > however we still want outbound data to behave in the same way and block.
> >
> > It's not clear to me from this description exactly where the situation
> > is that you need to write to the non-blocking socket. Is it on the
> > source or the destination? If the source, why are you writing to the
> > return path? If the destination, why are you marking the outgoing
> > return path as non-blocking?
>
> My understanding is that the semantics of set_nonblock() are to
> set non-blocking on all operations on the transport associated with
> the fd - and that it's true even if you dup() the fd; and so if you
> set non-blocking in one direction you get it in the other direction as well.
Ah.. yes, I think you're right.
> The (existing) destination side sets non-block (see process_incoming_migration
> in migration.c), and so it gets non-blocking on the incoming data stream, but
> that has the side effect that it's also going to be non-blocking on
> the destinations writes to the reverse-path; thus we need to be able
> to safely do writes from the destination reverse-path.
>
> The text is out of date, back in v2 the source used to use non-blocking
> for the return-path, but we managed to kill that off by using a thread
> for the return path in the source.
>
> How about changing the text to:
> --------
> The destination sets the fd to non-blocking on incoming migrations;
> this also affects the return path from the destination, and thus we
> need to make sure we can safely write to the return path.
Yes, I think that makes it clearer.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpyIenDPozES.pgp
Description: PGP signature