ab/1beb9ba1e49b33b1e752ca48f8ec39ab062f46

   1 Return-Path: <Sebastian@sspaeth.de>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id E271D431FD0\r
   6         for <notmuch@notmuchmail.org>; Fri,  9 Sep 2011 02:28:02 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.09\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         RCVD_IN_DNSWL_NONE=-0.0001, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id yi8SurlLrh6r for <notmuch@notmuchmail.org>;\r
  17         Fri,  9 Sep 2011 02:28:02 -0700 (PDT)\r
  18 Received: from homiemail-a21.g.dreamhost.com (caiajhbdcahe.dreamhost.com\r
  19         [208.97.132.74])\r
  20         by olra.theworths.org (Postfix) with ESMTP id 56AB2431FB6\r
  21         for <notmuch@notmuchmail.org>; Fri,  9 Sep 2011 02:28:02 -0700 (PDT)\r
  22 Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])\r
  23         by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 74D0E300074;\r
  24         Fri,  9 Sep 2011 02:28:00 -0700 (PDT)\r
  25 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sspaeth.de; h=from:to:cc:subject\r
  26         :in-reply-to:references:date:message-id:mime-version:\r
  27         content-type; q=dns; s=sspaeth.de; b=H/MyrRbVrjowtj5bxvm/FjpBi3p\r
  28         sPfEbUxoquTx5iSraJSBhpuovdOeg3L/jSj3xpGtuM5PrjLwPVosvaD/KkWZO7oC\r
  29         3NjTpCHSAnWqjWvYqN6KO+QnQCnznxoUCEqwL0YS9DTWdVQ27G61ikpoQLP/CH03\r
  30         vMo+JekSj5M0S8sU=\r
  31 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sspaeth.de; h=from:to:cc\r
  32         :subject:in-reply-to:references:date:message-id:mime-version:\r
  33         content-type; s=sspaeth.de; bh=Lh9naPi1gWZHljnGPy86n6IGOf4=; b=e\r
  34         mGLl6f9P6y6WH19Kq6oDLgoBsM1ZHY+zauNHWDy178PPmr2TVtpDpPoaDgzlA0nN\r
  35         K5TyCAjMn/zBSNxoGBCOZKH0332rHd3FMzVhRgJKywrjQtLugAA4kwzShHV+uZ+J\r
  36         3xffsKSYEhxbn1VcGOaga/oSJpwQ0UC/Vo0TNenosQ=\r
  37 Received: from spaetzbook.sspaeth.de (unknown [84.55.211.141])\r
  38         (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
  39         (No client certificate requested)\r
  40         (Authenticated sender: fax@sspaeth.de)\r
  41         by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 47C23300072; \r
  42         Fri,  9 Sep 2011 02:27:58 -0700 (PDT)\r
  43 Received: by spaetzbook.sspaeth.de (sSMTP sendmail emulation);\r
  44         Fri, 09 Sep 2011 11:27:55 +0200\r
  45 From: Sebastian Spaeth <Sebastian@sspaeth.de>\r
  46 To: Austin Clements <amdragon@MIT.EDU>\r
  47 Subject: Re: Memory management practices\r
  48 In-Reply-To: <20110908151557.GM5688@mit.edu>\r
  49 References: <8739h1pbaq.fsf@gmail.com> <87pqjprzu2.fsf@gmail.com>\r
  50         <20110829183010.GA2605@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>\r
  51         <87liucyn7i.fsf@gmail.com> <87aaag3xaf.fsf@gmail.com>\r
  52         <CAH-f9WsfHUm_D-+wB89Lt9Wt=hjwDyywvJTK-0NwmHRg0TUsxQ@mail.gmail.com>\r
  53         <CAH-f9WveBfvmv2jOF+C81OeeQJt06g6U0q3J_idHrs60DLw7+g@mail.gmail.com>\r
  54         <87zkiff8in.fsf@SSpaeth.de> <20110908151557.GM5688@mit.edu>\r
  55 User-Agent: Notmuch/0.7-19-gee4579a (http://notmuchmail.org) Emacs/23.2.1\r
  56         (x86_64-pc-linux-gnu)\r
  57 Date: Fri, 09 Sep 2011 11:27:55 +0200\r
  58 Message-ID: <8762l22hgk.fsf@SSpaeth.de>\r
  59 MIME-Version: 1.0\r
  60 Content-Type: multipart/signed; boundary="=-=-=";\r
  61         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  62 Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,\r
  63         Bart Massey <bart@cs.pdx.edu>, notmuch <notmuch@notmuchmail.org>\r
  64 X-BeenThere: notmuch@notmuchmail.org\r
  65 X-Mailman-Version: 2.1.13\r
  66 Precedence: list\r
  67 List-Id: "Use and development of the notmuch mail system."\r
  68         <notmuch.notmuchmail.org>\r
  69 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  70         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  71 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  72 List-Post: <mailto:notmuch@notmuchmail.org>\r
  73 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  74 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  75         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  76 X-List-Received-Date: Fri, 09 Sep 2011 09:28:03 -0000\r
  77 \r
  78 --=-=-=\r
  79 \r
  80 On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements <amdragon@MIT.EDU> wrote:\r
  81 > In general, a garbage collector can't make any guarantees about\r
  82 > finalization order.  When a collection of objects all become\r
  83 > unreachable simultaneously (for example, the last reference to any\r
  84 > Messages object is dropped, causing the Query object and the Message\r
  85 > object to both become unreachable), the garbage collector *could*\r
  86 > finalize the Query first (causing talloc to free the\r
  87 > notmuch_messages_t) and then the Messages object (causing it to\r
  88 > crash).  There's no guarantee in general because, in the presence of\r
  89 > cycles, there is no meaningful finalization order.\r
  90 \r
  91 Right, but that should not pose a problem for python. If e.g. both a\r
  92 Query and derived Message objects become unreachable, the python objects\r
  93 would not care which object is ditched and deleted first. Currently, it\r
  94 seems that we finalize the Messages first, and the Query second. But we\r
  95 would not fail if the Query were finalized first. Granted, the\r
  96 underlying libnotmuch Message objects were torn away while the python\r
  97 Message objects were still around. But they would ultimately also be\r
  98 sweeped away, and that would not cause any problems.\r
  99 \r
 100 But I am sure that I am missing out something. I'll leave this\r
 101 discussion to the pros :-).\r
 102 \r
 103 Sebastian\r
 104 \r
 105 --=-=-=\r
 106 Content-Type: application/pgp-signature\r
 107 \r
 108 -----BEGIN PGP SIGNATURE-----\r
 109 Version: GnuPG v1.4.11 (GNU/Linux)\r
 110 \r
 111 iEYEARECAAYFAk5p3BsACgkQVYX1jMgnoGIDRwCeMfZX2i6SSnvUe3zcBGZwaXF5\r
 112 CwQAn1icx+9HaE001I3Fv+4wnGMOubXM\r
 113 =1NuA\r
 114 -----END PGP SIGNATURE-----\r
 115 --=-=-=--\r