From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ian Zimmerman Newsgroups: gmane.emacs.help Subject: Re: From Gnus to mu4e Date: Fri, 28 Aug 2015 08:31:26 -0700 Message-ID: <20150828145303.19310.0B5C0550@ahiker.mooo.com> References: <87d1yhpsbr.fsf@free.fr> <87lhczyl1p.fsf@free.fr> <87a8tezf7x.fsf@free.fr> <87vbc0pgkp.fsf@free.fr> <20150827233408.GD30233@chitra.no-ip.org> <20150827234228.11079.2CAD2C13@ahiker.mooo.com> <20150828001444.GF30233@chitra.no-ip.org> <20150828001629.11433.17209627@ahiker.mooo.com> <20150828090619.GH30233@chitra.no-ip.org> Reply-To: help-gnu-emacs@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1440775907 1949 80.91.229.3 (28 Aug 2015 15:31:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2015 15:31:47 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 28 17:31:47 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZVLd4-0005Jr-Ln for geh-help-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 17:31:46 +0200 Original-Received: from localhost ([::1]:48426 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVLd3-0001SO-Sq for geh-help-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 11:31:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVLco-0001NG-Pr for help-gnu-emacs@gnu.org; Fri, 28 Aug 2015 11:31:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVLcn-0007az-N9 for help-gnu-emacs@gnu.org; Fri, 28 Aug 2015 11:31:30 -0400 Original-Received: from disorder-1-pt.tunnel.tserv3.fmt2.ipv6.he.net ([2001:470:1f04:51a::2]:47573 helo=acedia.primate.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVLcn-0007a0-F5 for help-gnu-emacs@gnu.org; Fri, 28 Aug 2015 11:31:29 -0400 Original-Received: from acedia.primate.net (localhost [127.0.0.1]) by acedia.primate.net (8.14.9/8.14.9/Debian-4) with ESMTP id t7SFVRLx026817 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 28 Aug 2015 08:31:27 -0700 Original-Received: (from itz@localhost) by acedia.primate.net (8.14.9/8.14.9/Submit) id t7SFVQB1026812 for help-gnu-emacs@gnu.org; Fri, 28 Aug 2015 08:31:26 -0700 X-Authentication-Warning: acedia.primate.net: itz set sender to itz@buug.org using -f Original-Received: from itz by ahiker.mooo.com with local (Exim 4.80) (envelope-from ) id 1ZVLck-0005A9-LR for help-gnu-emacs@gnu.org; Fri, 28 Aug 2015 08:31:26 -0700 Content-Disposition: inline In-Reply-To: <20150828090619.GH30233@chitra.no-ip.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:470:1f04:51a::2 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:106904 Archived-At: On 2015-08-28 11:06 +0200, Suvayu Ali wrote: > And essentially this is the beauty of the maildir > format, data integrity. I agree, but that is not the same as absence of races. See below. > Hopefully I have explained myself clearly enough. Or maybe you were > trying to say something else? In that case please feel free to stop me. We have different definitions of "race". To me, corruption is not a necessary ingredient; a race is just a situation where two (or more) threads or processes mutate data in ways that are independent (ie. commutative) in the abstract, and yet the final state of the data depends on the order of the changes. A race can even be completely harmless if the two concrete representations of the final state in fact represent the same abstract state. An extreme example of that would be a log structured system, where the difference is simply in the order of the log records left by the changes. Yes, this is a race by my definition; but it's a feature, not a bug :-) > When MUA 2 fails, it is easily handled by reporting to the user and not > trying to commit the changes again. E.g. in mutt, this is handled by > telling the user something like: file does not exist (I don't recall the > exact phrasing), and keeping the folder state as is. I don't know about you, but if I got this blurb from my MUA I would first stare at the screen for minutes, repeating "wtf wtf", then (if I was having a good day) investigate, and finally mutate the state of my computer to ensure exclusive access :-) IOW, I don't want such weirdness to happen, whether I call it "race" or not. Lastly, it is not even clear what we should consider "corruption", or the absence of it. Is internal consistency enough? Consider the classic motivating example for database transactions, with two threads trying to update an account balance datum, and only one succeeding. Let's say there's no separate transactions table (a stretch, I know). Then the data after the mixup is internally consistent; there just aren't many ways that a single numerical value can be incosistent :-) But it doesn't reflect reality, so maybe it is corrupt? And to close the circle, this example in fact has analogy with our maildir situation: the MUA trying to set the "Replied" flag presumably just sent off a reply. So the failure to set the flag means the maildir state, while internally consistent, doesn't reflect reality. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.