On a somewhat related note, I've noticed that getting getting threads is much 
slower than getting messages that match the same query, extracting the thread 
IDs, and then getting the messages for each of those threads. This seems to be 
the case both in the old and new APIs — any ideas?

Cheers,

Lars


On Thu, 06 Feb 2025 13:26:53 +0100, Floris Bruynooghe <flub@devork.be> wrote:
> On Wed 05 Feb 2025 at 20:01 -0700, Lars Kotthoff wrote:
> 
> >> Hum, it seems *all* iterators are destroyed too early?  I think it is
> >> just luck that this works for threads, also the 2nd for loop in the
> >> above code seems like just luck.
> >
> > Yes — looks like the memory management doesn't necessarily free everything 
> > immediately; that's what must be causing it to work sometimes.
> >
> >> (FWIW I get a SIGABRT instead of SIGSEGV from these.)
> >
> > Ah, you must be on a Mac :)
> 
> No, on Debian Linux...
> 
> >> Try removing the `self.destroy()` line from
> >> `_base.NotmuchIter.__next__()`.  I'm not sure why that destroy was ever
> >> there, I think it is a bug to call free on the iterator so early.
> >
> > Done that; seems to work now.
> >
> >> I can do a proper patch in the next few days probably if no one beats me
> >> to it.
> >
> > Patch attached — I removed a similarly troublesome _destroy() in another place 
> > and added unit tests to check this. FWIW, I wasn't able to get it to segfault 
> > with the threads or properties iterator, even though it should. I suspect 
> > notmuch's memory management; added the tests just in case.
> 
> Patch looks good!  Thanks for this, and thanks for adding the tests!
> [...]
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org