Pointer ownership

classic Classic list List threaded Threaded
5 messages Options
Dirk Van Haerenborgh-2 Dirk Van Haerenborgh-2
Reply | Threaded
Open this post in threaded view
|

Pointer ownership

Hi all,

I'm the main author for these notmuch rust bindings: https://github.com/vhdirk/notmuch-rs
In making these bindings safe, it's very important to understand when memory is reclaimed by notmuch (and when not). And I'm having a hard time deducing that from the documentation. I've built a couple of c test routines, but I'm getting none the wiser from that.

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.

Kind regards
-Dirk 



_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: Pointer ownership

Dirk Van Haerenborgh <[hidden email]> 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



_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Dirk Van Haerenborgh-2 Dirk Van Haerenborgh-2
Reply | Threaded
Open this post in threaded view
|

Re: Pointer ownership

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 <[hidden email]> wrote:
Dirk Van Haerenborgh <[hidden email]> 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




_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|

Re: Pointer ownership

Dirk Van Haerenborgh <[hidden email]> writes:

> 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 :)

It's still (transitively) owned by the query in that case, since the
threads are owned by the query.

d
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
rhn-2 rhn-2
Reply | Threaded
Open this post in threaded view
|

Re: Pointer ownership

In reply to this post by David Bremner-2
On Mon, 17 Dec 2018 08:22:27 +0900
David Bremner <[hidden email]> wrote:

> Dirk Van Haerenborgh <[hidden email]> 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
>

Thanks for the answer. When you're saying that threads are "lazily constructed", I assume that it doesn't really matter for the actual API? From that, I'm guessing that the message handover starts and ends within a single API call, before the caller ever has a chance to see the message handle?

The importance of lifetimes in Rust only concerns what the API guarantees about the validity of handles/data, so the implementation is free to do whatever as long as those are not impacted.

BTW, I've submitted a patch making the guarantee explicitly stated in the docs, see [hidden email] . Reviews welcome, a merge is even more welcome.

Cheers,
rhn
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch