From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPpmR-0006D2-Uw for qemu-devel@nongnu.org; Sat, 11 Jul 2009 23:31:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPpmN-0006CH-HK for qemu-devel@nongnu.org; Sat, 11 Jul 2009 23:31:11 -0400 Received: from [199.232.76.173] (port=47752 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPpmN-0006CE-CB for qemu-devel@nongnu.org; Sat, 11 Jul 2009 23:31:07 -0400 Received: from an-out-0708.google.com ([209.85.132.250]:6146) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MPpmN-0003iY-2G for qemu-devel@nongnu.org; Sat, 11 Jul 2009 23:31:07 -0400 Received: by an-out-0708.google.com with SMTP id c38so848365ana.37 for ; Sat, 11 Jul 2009 20:31:06 -0700 (PDT) Message-ID: <4A5958F8.3090306@codemonkey.ws> Date: Sat, 11 Jul 2009 22:31:04 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] move vm stop/start to migrate_set_state References: <1247140059-5034-1-git-send-email-pbonzini@redhat.com> <1247140059-5034-3-git-send-email-pbonzini@redhat.com> <4A55F46F.6060705@codemonkey.ws> <4A55F510.5090801@redhat.com> <4A55F641.6000701@codemonkey.ws> <20090710231424.GD30322@shareable.org> <4A57E3AA.5020305@codemonkey.ws> <20090711014207.GM30322@shareable.org> In-Reply-To: <20090711014207.GM30322@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Paolo Bonzini , qemu-devel@nongnu.org Jamie Lokier wrote: > If you get an error during the last write(), I wouldn't trust that to > mean the recipient will definitely not see the data you wrote. (Enjoy > the double negative). It's another variation of the handshake > uncertainty, this time reflected in what write() should report when > it's uncertain about a network transmission. If it reports an error > when it's uncertain, then you can't trust that a write() error means > the data was not written, only that a problem was detected. > I think you're stretching here. If it really were the case that write() could actually result in data being sent out the wire and yet still returning an error, it would make all error handling in Unix unmanagable. I can't believe this is possible in Linux and without an actual counter-example, I'm inclined to believe the same is true for every other OS out there. Regards, Anthony Liguori