Re: Memory management practices
authorSebastian Spaeth <Sebastian@sspaeth.de>
Fri, 9 Sep 2011 09:27:55 +0000 (11:27 +0200)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:39:24 +0000 (09:39 -0800)
ab/1beb9ba1e49b33b1e752ca48f8ec39ab062f46 [new file with mode: 0644]

diff --git a/ab/1beb9ba1e49b33b1e752ca48f8ec39ab062f46 b/ab/1beb9ba1e49b33b1e752ca48f8ec39ab062f46
new file mode 100644 (file)
index 0000000..2769fdf
--- /dev/null
@@ -0,0 +1,115 @@
+Return-Path: <Sebastian@sspaeth.de>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id E271D431FD0\r
+       for <notmuch@notmuchmail.org>; Fri,  9 Sep 2011 02:28:02 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.09\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+       RCVD_IN_DNSWL_NONE=-0.0001, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id yi8SurlLrh6r for <notmuch@notmuchmail.org>;\r
+       Fri,  9 Sep 2011 02:28:02 -0700 (PDT)\r
+Received: from homiemail-a21.g.dreamhost.com (caiajhbdcahe.dreamhost.com\r
+       [208.97.132.74])\r
+       by olra.theworths.org (Postfix) with ESMTP id 56AB2431FB6\r
+       for <notmuch@notmuchmail.org>; Fri,  9 Sep 2011 02:28:02 -0700 (PDT)\r
+Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])\r
+       by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 74D0E300074;\r
+       Fri,  9 Sep 2011 02:28:00 -0700 (PDT)\r
+DomainKey-Signature: a=rsa-sha1; c=nofws; d=sspaeth.de; h=from:to:cc:subject\r
+       :in-reply-to:references:date:message-id:mime-version:\r
+       content-type; q=dns; s=sspaeth.de; b=H/MyrRbVrjowtj5bxvm/FjpBi3p\r
+       sPfEbUxoquTx5iSraJSBhpuovdOeg3L/jSj3xpGtuM5PrjLwPVosvaD/KkWZO7oC\r
+       3NjTpCHSAnWqjWvYqN6KO+QnQCnznxoUCEqwL0YS9DTWdVQ27G61ikpoQLP/CH03\r
+       vMo+JekSj5M0S8sU=\r
+DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sspaeth.de; h=from:to:cc\r
+       :subject:in-reply-to:references:date:message-id:mime-version:\r
+       content-type; s=sspaeth.de; bh=Lh9naPi1gWZHljnGPy86n6IGOf4=; b=e\r
+       mGLl6f9P6y6WH19Kq6oDLgoBsM1ZHY+zauNHWDy178PPmr2TVtpDpPoaDgzlA0nN\r
+       K5TyCAjMn/zBSNxoGBCOZKH0332rHd3FMzVhRgJKywrjQtLugAA4kwzShHV+uZ+J\r
+       3xffsKSYEhxbn1VcGOaga/oSJpwQ0UC/Vo0TNenosQ=\r
+Received: from spaetzbook.sspaeth.de (unknown [84.55.211.141])\r
+       (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       (Authenticated sender: fax@sspaeth.de)\r
+       by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 47C23300072; \r
+       Fri,  9 Sep 2011 02:27:58 -0700 (PDT)\r
+Received: by spaetzbook.sspaeth.de (sSMTP sendmail emulation);\r
+       Fri, 09 Sep 2011 11:27:55 +0200\r
+From: Sebastian Spaeth <Sebastian@sspaeth.de>\r
+To: Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: Memory management practices\r
+In-Reply-To: <20110908151557.GM5688@mit.edu>\r
+References: <8739h1pbaq.fsf@gmail.com> <87pqjprzu2.fsf@gmail.com>\r
+       <20110829183010.GA2605@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>\r
+       <87liucyn7i.fsf@gmail.com> <87aaag3xaf.fsf@gmail.com>\r
+       <CAH-f9WsfHUm_D-+wB89Lt9Wt=hjwDyywvJTK-0NwmHRg0TUsxQ@mail.gmail.com>\r
+       <CAH-f9WveBfvmv2jOF+C81OeeQJt06g6U0q3J_idHrs60DLw7+g@mail.gmail.com>\r
+       <87zkiff8in.fsf@SSpaeth.de> <20110908151557.GM5688@mit.edu>\r
+User-Agent: Notmuch/0.7-19-gee4579a (http://notmuchmail.org) Emacs/23.2.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Fri, 09 Sep 2011 11:27:55 +0200\r
+Message-ID: <8762l22hgk.fsf@SSpaeth.de>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,\r
+       Bart Massey <bart@cs.pdx.edu>, notmuch <notmuch@notmuchmail.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Fri, 09 Sep 2011 09:28:03 -0000\r
+\r
+--=-=-=\r
+\r
+On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> In general, a garbage collector can't make any guarantees about\r
+> finalization order.  When a collection of objects all become\r
+> unreachable simultaneously (for example, the last reference to any\r
+> Messages object is dropped, causing the Query object and the Message\r
+> object to both become unreachable), the garbage collector *could*\r
+> finalize the Query first (causing talloc to free the\r
+> notmuch_messages_t) and then the Messages object (causing it to\r
+> crash).  There's no guarantee in general because, in the presence of\r
+> cycles, there is no meaningful finalization order.\r
+\r
+Right, but that should not pose a problem for python. If e.g. both a\r
+Query and derived Message objects become unreachable, the python objects\r
+would not care which object is ditched and deleted first. Currently, it\r
+seems that we finalize the Messages first, and the Query second. But we\r
+would not fail if the Query were finalized first. Granted, the\r
+underlying libnotmuch Message objects were torn away while the python\r
+Message objects were still around. But they would ultimately also be\r
+sweeped away, and that would not cause any problems.\r
+\r
+But I am sure that I am missing out something. I'll leave this\r
+discussion to the pros :-).\r
+\r
+Sebastian\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iEYEARECAAYFAk5p3BsACgkQVYX1jMgnoGIDRwCeMfZX2i6SSnvUe3zcBGZwaXF5\r
+CwQAn1icx+9HaE001I3Fv+4wnGMOubXM\r
+=1NuA\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r