From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 6D0896DE0BA2 for ; Thu, 20 Dec 2018 01:22:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-0.185, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2SBGkSYI5iP for ; Thu, 20 Dec 2018 01:22:19 -0800 (PST) Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by arlo.cworth.org (Postfix) with ESMTPS id 444576DE0BB8 for ; Thu, 20 Dec 2018 01:22:19 -0800 (PST) Received: by mail-vk1-f178.google.com with SMTP id s184so212057vkd.6 for ; Thu, 20 Dec 2018 01:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SRpXUKxAbwbXu5zWXZX/O4yiqzXrGYOuYzocfQq9Czc=; b=Vmyo0kwnbyywuCylXMS5EhbmsPophMlEye7gw4T/rmos5/NT19LeaNUluPTPzF7aeg Kcg5IUOsV5UwZ690EnOBREhSPsHlLyby50kTD2m3YB2+4cQyeZ9ngNP9Ts2hw3ziUS3G d8jmCrfvEdK3ymbitZYU7WjE2wOIc94duvWre7B9NwwCA/Otq86SCeLXWHwiN0i3/T6C ZAC6+G6F0iFoaPyCNVXZCPMEY8Tq/pe/klmv1Xsd7mof6WJbNogZsagkI9ZnAhn5uKT7 KWc/eYdVpZYrYVBb3NdagU/ogu9+Y2URt6srGuSy6dAoNAYjdfKQkPPNyr05M5zF9DXE rasw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SRpXUKxAbwbXu5zWXZX/O4yiqzXrGYOuYzocfQq9Czc=; b=TbKAXnMcrhHcV0sUhcMpbCR33NRpYMSisX6wMEUxkxh6lCl3KTcxNda0Q7EdXoIN5a FDLoxV3GKXxwWLwJn5H2yCo5fdsnW7tfzS6FaHYNs33UBy6pAfXNIY/LDQVSms+sdi2y fSZ9PkTxM3G19wcZMGegOaf/5SdUnZStIvmyddKL66ZO0uHOBID0d/Wf2mklJvM7KEdf h9WAjXuMZaeOkMmFjoX2m4LpT15XjtRVLooYhA7kEprNFKGEO+e1sHE3Is0JUUaCfh3O NSfLcQJBVyXrtwa5eftJ+lBXZq3Gu3RS6I6GaoW/omsmA2ZCFN65iureNBdSf9hBbSLF 32dg== X-Gm-Message-State: AA+aEWYzIA23a7q6HsLdWb4IJHdN2VI3qaw7wUG6cLvtbaoyiFvpDUO9 FDNGvXn0K4LSDqdhmyj0OEAGXV67j/IhdOR/VQI= X-Google-Smtp-Source: AFSGD/Xs9/7Gys9JYZop/pgIk/e/AmVhVr8+E3ORGwbSFpHgUf6rSguQM++dXCS9VmqWJjnJzEwDm4HWj3KCS5BLlt0= X-Received: by 2002:a1f:a8c5:: with SMTP id r188mr10912024vke.44.1545297737287; Thu, 20 Dec 2018 01:22:17 -0800 (PST) MIME-Version: 1.0 References: <87imzt9hvw.fsf@tethera.net> In-Reply-To: <87imzt9hvw.fsf@tethera.net> From: Dirk Van Haerenborgh Date: Thu, 20 Dec 2018 10:21:41 +0100 Message-ID: Subject: Re: Pointer ownership To: David Bremner Cc: notmuch@notmuchmail.org, Carl Worth Content-Type: multipart/alternative; boundary="000000000000b40db4057d70aa5f" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 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: Thu, 20 Dec 2018 09:22:21 -0000 --000000000000b40db4057d70aa5f Content-Type: text/plain; charset="UTF-8" Thanks. For the most part, that's what I ended up with, but the thread 'stealing' a message will be quite hard to implement in Rust, I guess. When using notmuch_query_search_messages, I was assuming the resulting individual messages to be owned by the query. So, if at a later point in time, one uses notmuch_query_search_threads, will the ownership of a previous message abruptly be transferred from query to thread? I do want to be able to run *_destroy at some point :) -Dirk On Thu, 20 Dec 2018 at 10:11, David Bremner wrote: > Dirk Van Haerenborgh writes: > > > > For instance, when iterating messages from a thread: Can one still use a > > notmuch_message_t* when the thread is destroyed? > > Are the individual > > messages 'owned' by the thread, or only by the query? Same question for > > 'replies'. > > > > Could someone please shed some light on this? I'd very much appreciate > it. > > It's hierarchical (the underlying allocator is talloc). So threads are > owned by the corresponding query, and messages are owned by threads. > > Assuming replies refers to notmuch_message_get_replies, then those are > owned by some thread as well. > > Threads are somewhat lazily constructed, so there's a time where a > message is owned by a query before it is "stolen" by a thread. > > This is all Carl's design, so hopefully he'll correct me if I said > anything outrageously wrong. > > d > > > > --000000000000b40db4057d70aa5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks.

For the most part, t= hat's what I ended up with, but the thread 'stealing' a message= will be quite hard to implement in Rust, I guess.
When using not= much_query_search_messages, I was assuming the resulting individual message= s to be owned by the query.
So, if at a later point in time, one = uses notmuch_query_search_threads, will the ownership of a previous message= abruptly be
transferred from query to thread?
I do wan= t to be able to run *_destroy at some point :)

-Di= rk


On T= hu, 20 Dec 2018 at 10:11, David Bremner <david@tethera.net> wrote:
Dirk Van Haerenborgh <vhdirk@gmail.com> writes:


> For instance, when iterating messages from a thread: Can one still use= a
> notmuch_message_t* when the thread is destroyed?
> Are the individual
> messages 'owned' by the thread, or only by the query? Same que= stion for
> 'replies'.
>
> Could someone please shed some light on this? I'd very much apprec= iate it.

It's hierarchical (the underlying allocator is talloc). So threads are<= br> owned by the corresponding query, and messages are owned by threads.

Assuming replies refers to notmuch_message_get_replies, then those are
owned by some thread as well.

Threads are somewhat lazily constructed, so there's a time where a
message is owned by a query before it is "stolen" by a thread.
This is all Carl's design, so hopefully he'll correct me if I said<= br> anything outrageously wrong.

d



--000000000000b40db4057d70aa5f--