From e16eabcb979c01310074767ffa0d0fea35a6b8ba Mon Sep 17 00:00:00 2001 From: Gaute Hope Date: Sat, 17 Jan 2015 15:12:05 +0000 Subject: [PATCH] Re: DatabaseModifiedErrors causing troubles --- e6/62a9e3fa0f715cdb76f3fd599d2beac383988a | 117 ++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 e6/62a9e3fa0f715cdb76f3fd599d2beac383988a diff --git a/e6/62a9e3fa0f715cdb76f3fd599d2beac383988a b/e6/62a9e3fa0f715cdb76f3fd599d2beac383988a new file mode 100644 index 000000000..1b8f503e3 --- /dev/null +++ b/e6/62a9e3fa0f715cdb76f3fd599d2beac383988a @@ -0,0 +1,117 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 07952431FC2 + for ; Sat, 17 Jan 2015 07:11:14 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 1.738 +X-Spam-Level: * +X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 + tests=[DNS_FROM_AHBL_RHSBL=2.438, RCVD_IN_DNSWL_LOW=-0.7] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id G5hGtFTheALN for ; + Sat, 17 Jan 2015 07:11:10 -0800 (PST) +Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com + [209.85.217.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 82288431FAF + for ; Sat, 17 Jan 2015 07:11:10 -0800 (PST) +Received: by mail-lb0-f178.google.com with SMTP id u14so22486330lbd.9 + for ; Sat, 17 Jan 2015 07:11:09 -0800 (PST) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:date:from:subject:to:references:in-reply-to + :user-agent:message-id:mime-version:content-type + :content-transfer-encoding; + bh=DK+6mZO+/S86WYzsq0MAvJ4SphbYzqXWQVHz6n9iBCk=; + b=WIk3yRbQITq3ZPeU51DhXMDAif8598kkOMAKu/Ai58bugYb8yPBKuWCSw1LMfFW6xv + /MA3m8InGlkR/OwQNuhfwjR9wofF6g2nbaPcQadXUqEAsvYAOD02Ub9sal23g3E2Lai0 + gko7xcCoBbElqfWwfukgLZJIG3zl3XW5cC7bH/zV3YsJYDG0Bx7noz4EHZKWz6tdagmx + Z/CE5T7Y8pF0tWqiZxr2dTRGumGxkeO2jU0wP2QFj7T1/D1xJ7/FBHx8NFu42Z5/rQL3 + AeOwOnw8ZrJK7XglvwkcpSRBORypF6wQ9manuvKO1IWXi43r7Y78vL5k3akmAHuPa6n9 + yZyQ== +X-Gm-Message-State: + ALoCoQlygMM8yAtHloUYekN7vapZzJdT7yzxJfK8yNpZChQ7m/l210xCUfltLO87GOoTfmOqu7nU +X-Received: by 10.152.26.201 with SMTP id n9mr21216383lag.50.1421507469122; + Sat, 17 Jan 2015 07:11:09 -0800 (PST) +Received: from localhost (c2774BF51.dhcp.as2116.net. [81.191.116.39]) + by mx.google.com with ESMTPSA id y11sm815150lba.5.2015.01.17.07.11.06 + (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Sat, 17 Jan 2015 07:11:07 -0800 (PST) +Date: Sat, 17 Jan 2015 15:12:05 +0000 +From: Gaute Hope +Subject: Re: DatabaseModifiedErrors causing troubles +To: David Bremner , notmuch +References: + + <87bnmkgr57.fsf@maritornes.cs.unb.ca> + <1421493070-astroid-1-4x8pflg7mc-1327@strange> + <87fvb9bnf8.fsf@maritornes.cs.unb.ca> +In-Reply-To: <87fvb9bnf8.fsf@maritornes.cs.unb.ca> +User-Agent: astroid/vv0.1-42-ge9d4344b (https://github.com/gauteh/astroid) +Message-Id: <1421507092-astroid-4-sde37j1ij5-1327@strange> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8; format=flowed +Content-Transfer-Encoding: quoted-printable +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sat, 17 Jan 2015 15:11:14 -0000 + +Excerpts from David Bremner's message of January 17, 2015 13:29: +> Gaute Hope writes: +> +>> +>> Hi David, +>> +>> Would it be possible with an error code that I could compare against in +>> stead? It would then work a bit like a global instance of the gmime +>> error. It could even be a preparation step against a gmime-error-style +>> solution in the far future. +>> +>> I am sure you know all the bad reasons for using a strcmp with strings +>> such as small (subtle) changes making them useless or future +>> localization of notmuch. This solution is in my opinion worse than the +>> current situation, it will lock things in and create problems for future +>> API compatability and application maintainers. I would rather wait for +>> or spend some time on a more general solution. +> +> I don't agree it's worse than the current situation but I take your +> point it isn't ideal. We could do some kind "errno" in the database +> structure. I think there are not that many functions with this +> unhelpful error return type. Based on a scan of notmuch.h, I see +> +> notmuch_query_search_threads +> notmuch_query_search_messages +> +> and the two count functions that I already posted API breaking patches +> for. It might be better just to update the API (either adding versions +> with error returns, or just forcing people to change) for these +> functions. Otherwise we have two different ways of returning status +> codes, and the "errno" is only used some of the time. + +Yeah - a consistent way of doing this would in my opinion be very +useful. Also, many other functions could be affected by outside +processes as well (notmuch new, notmuch tag) that do not necessarily +violate the thread-safety restrictions on xapian / notmuch. Errors in +these functions, and importantly which error, are currently hard to +catch and identify (say notmuch_messages_move_to_next). The same error +reporting system could be used for these. With a flexible error system +we could fix these as they are discovered. + +Cheers, Gaute + += -- 2.26.2