From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrD47-0002dV-Ep for qemu-devel@nongnu.org; Wed, 19 Nov 2014 16:45:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrD41-0006rQ-JT for qemu-devel@nongnu.org; Wed, 19 Nov 2014 16:45:31 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:51637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrD40-0006qx-Um for qemu-devel@nongnu.org; Wed, 19 Nov 2014 16:45:25 -0500 Date: Thu, 20 Nov 2014 08:12:19 +1100 From: David Gibson Message-ID: <20141119211219.GJ2867@voom.redhat.com> References: <1412358473-31398-1-git-send-email-dgilbert@redhat.com> <1412358473-31398-17-git-send-email-dgilbert@redhat.com> <20141103034600.GL8949@voom.redhat.com> <20141103132244.GF3480@work-vm> <20141118035200.GA2867@voom.redhat.com> <20141119170650.GK2355@work-vm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6THr7QwYWIbrk6Kt" Content-Disposition: inline In-Reply-To: <20141119170650.GK2355@work-vm> Subject: Re: [Qemu-devel] [PATCH v4 16/47] Return path: Source handling of return path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, cristian.klein@cs.umu.se, qemu-devel@nongnu.org, amit.shah@redhat.com, yanghy@cn.fujitsu.com --6THr7QwYWIbrk6Kt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 19, 2014 at 05:06:50PM +0000, Dr. David Alan Gilbert wrote: > * David Gibson (david@gibson.dropbear.id.au) wrote: > > On Mon, Nov 03, 2014 at 01:22:45PM +0000, Dr. David Alan Gilbert wrote: > > > * David Gibson (david@gibson.dropbear.id.au) wrote: > > > > On Fri, Oct 03, 2014 at 06:47:22PM +0100, Dr. David Alan Gilbert (g= it) wrote: > > > > > From: "Dr. David Alan Gilbert" > > > > >=20 > > > > > Open a return path, and handle messages that are received upon it. > > > > >=20 > > > > > Signed-off-by: Dr. David Alan Gilbert > > > >=20 > > > > [snip] > > > > > @@ -414,6 +448,11 @@ static void migrate_fd_cancel(MigrationState= *s) > > > > > int old_state ; > > > > > trace_migrate_fd_cancel(); > > > > > =20 > > > > > + if (s->return_path) { > > > > > + /* shutdown the rp socket, so causing the rp thread to s= hutdown */ > > > > > + qemu_file_shutdown(s->return_path); > > > >=20 > > > > Terminating the rp thread via shutting down its file seems roundabo= ut, > > > > and kind of dependent on the socket file implementation. > > >=20 > > > The rp thread might be in the middle of a blocking read()/recv() > > > so I'm doing a shutdown() to cause those to exit; once I have to do t= hat > > > anyway it didn't seem necessary to add anything etra. > >=20 > > Hm. I don't recall, does the rp thread need to do some cleanup at > > this point? Otherwise pthread_cancel() should kill a thread, even if > > it's blocked at the moment. >=20 > It was Paolo's idea to use shutdown() and I agree - it works well; > I'd originally thought about using pthread_cancel but it seemed to be > generally disliked - you have to be very careful to either know exactly > the points at which it might be killed (if you use the deferred version) > or be prepared to deal with your thread disappearing at any time and > ensure your data structures are always consistent. In addition there > was some concern that there was no Windows equivalent to pthread_cancel. Hmm, yeah all right. > > > > [snip] > > > > > +__attribute__ (( unused )) /* Until later in patch series */ > > > > > +static int open_outgoing_return_path(MigrationState *ms) > > > > > +{ > > > > > + > > > > > + ms->return_path =3D qemu_file_get_return_path(ms->file); > > > >=20 > > > > So, another reason this get_return_path abstraction doesn't seem ri= ght > > > > to me, is that it's not obvious that for non-socket file types, the > > > > source and destination side "get return path" operations would > > > > necessarily be the same. > > >=20 > > > However, since the implementation of the get_return_path is a method > > > on the particular implementation, and it can be different for a=20 > > > qemu_file opened for read or write, then that non-socket file type > > > could implement it how it likes including something like shutdown). > >=20 > > So, I'm a little less bothered by this since I realised that QemuFile > > is basically only used for migration streams, not for other file type > > operations. The fact that that makes QemuFile a really bad name is a > > different matter. >=20 > Yes, but hey we've got FILE* in C anyway, so it might be bad, but it's > not inconsitent. Uh.. not following the analogy here, sorry. > > The return path operation is quite specific to a migration stream, and > > doesn't really belong with a "file" abstraction. >=20 > I think the bit that's specific, is as you say that I don't know whether > I need it until later. >=20 > > The case I've been considering where it's not easy to see how to > > abstract this is that of a pipe - in that case it will be necessary to > > open a second pipe from destination to source, which probably needs > > some preliminary work when first opening the connection, and therefore > > can't easily be encapsulated into a "get return path" callback. >=20 > I'm OK with some transports not supporting this; I check for it and > error out. At a higher level I do send an 'open_return_path' command > from src->dest early on to say I'm going to want a return path, I guess > a pipe might be able to open that fd then and pass it back over the origi= nal > fd? But that might be hairy. You can pass fds over Unix sockets, but not over pipes AFAIK. > > The abstraction of the shutdown is another question again - I can't > > think of any other file type which has an operation similar in effect > > to shutdown(), so it seems really socket specific. Which is another > > reason I'm not convinced telling the rp thread to die via its stream > > is a good idea. >=20 > I'd be OK with setting some flag or similar at the same time if that > would help; but I don't think there's a safe posix'y way of killing a > thread that might be stuck in a recv()/read() other than shutdown(). >=20 > Dave >=20 --=20 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 --6THr7QwYWIbrk6Kt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUbQezAAoJEGw4ysog2bOSZfwP/0xkqR9pVwNL4xCQwXfolJsG SRLZ7PZlqPFs6wrsfwHo/0s5YGjMNbQAGmkr2Lu5i8OOMHCM4aUyV7Cc7APmUreC hsp9JHkwq0A5rfdFfpVQ3AxRkvvD7mMLSodXPvSNnastwgKmST7aq2BNnwivuqs0 Kio0Qkr0QBnkQ5LfimOdNupMT2bB5X0DVy5W8885u6pt1Ar3CjRXNGPx86N3tFGg /VSP5EU3rwD756CSLzaxNSDCjN3SbHqGhltfaFiAx08AZqIqpa8DuOeWK7jVF8nP 58syuU1QICyUublszGdKasb3ESbL20FUCole5Y2jQD8BuyNzzhAEEyZB8zUCAu2Q tOkEMbUsWmG47qbLtdApJ2uemBXvPaTgSHfER+yUtI43Vl0gwJTNZn3i/rvBENMV mD4l7Z/ZWOa017jEAZiyGf4UptA6VdB2Qn8JyZmhs6QOyE7+ZS3HiuDbKY/ObxMN 2T8Fe3OjUWz14nkwlh1GCF60kZp8MmZP/87TCeGtO7ceqh2IZqxpUigVpgd/7voU BQXHGZ9plXJETGIgerO7ETzd/lLZndNz7rNRxPeS2BfOW27dWpyRLkbXDJ9Z22eO EjP7KCoABvEqw0J5/7d0pHAGJ9i5wU4f4Fs1xZzcDn8jR2d89XCietM0Ec4YqtS1 ol/IKqAdP+djhmSathOi =iQmh -----END PGP SIGNATURE----- --6THr7QwYWIbrk6Kt--