From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25758 invoked by alias); 14 Sep 2009 20:40:11 -0000 Received: (qmail 25748 invoked by uid 22791); 14 Sep 2009 20:40:11 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 20:40:07 +0000 Received: (qmail 16755 invoked from network); 14 Sep 2009 20:40:05 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Sep 2009 20:40:05 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: [patch] only update dcache after write succeeds Date: Mon, 14 Sep 2009 20:40:00 -0000 User-Agent: KMail/1.9.10 Cc: Doug Evans , "gdb-patches@sourceware.org" , Marc Khouzam , Greg Law , Hui Zhu References: <20090914191657.E32D6844C3@localhost> <4AAEA596.9040100@vmware.com> In-Reply-To: <4AAEA596.9040100@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909142140.09644.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00456.txt.bz2 On Monday 14 September 2009 21:20:38, Michael Snyder wrote: > > IOW, if some target method does return > 0, then the write succeeded, right? > > Are there different kinds of "success" in effect here? > > Well, maybe only in our case. ;-) > > If nobody else has any worries about it, I'm OK with it. > > ---- > * In our case (process record), it's a bad thing for the target > beneath to be called after the user has said "no". The user is saying "no" to the whole high level operation, not to a single partial transfer. In that case, you shouldn't even attempt to partial xfer in the target beneath, I would say. A thrown error for those cases looks like the way to go. Perhaps even better would be to be able to foretell if the transfer is going to be problematic and warn/query upfront, but it's hard in some cases. -- Pedro Alves