GNU bug report logs - #53877
29.0.50; [PATCH] async Gnus/nnml

Previous Next

Full log

View this message in rfc822 format

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: 53877 <at> debbugs.gnu.org
Subject: bug#53877: 29.0.50; [PATCH] async Gnus/nnml
Date: Tue, 08 Feb 2022 12:33:54 -0800

Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> Hi,
>
> I'm trying to have an asynchronous Gnus nnml backend. In the process, I
> found some things that I'd like to have first in nnmail.el and
> mail-sources.el (see patches).
>
> There is nothing asynchronous so far so Gnus behaviour shouldn't have
> changed that much.

Hi Manuel,

Thanks for working on this! Getting rid of `nnmail-article-buffer' looks
fine to me.

In the crash box patch, I wonder if we really need to change the name of
the option. It could be used as-is as a prefix, without really needing
to involve the user. Maybe changing the docstring would be enough?

In mail-source-fetch:

+            (dolist (box (mail-source-existing-crash-boxes))
+	      (message "Processing mail from %s..." box)
+	      (setq found (mail-source-callback callback box box))

You'll want to use cl-incf on `found' here (as in the other files).

In the nnmail cache mutex patch, I guess we're preparing for multiple
threads to potentially be writing to/reading from `nnmail-cache-buffer',
right? The mutex prevents concurrent access, but are we sure that
leftover text in the buffer won't confuse the regexp searches? Would it
be safer just to clear the buffer altogether after each transaction?

I'm not quite sure why you're refactoring out
`gnus-update-unread-group', is the idea that that will be used in other
places as well? Or is this the function that will get run in a thread
eventually?

Lastly, have you done your copyright assignment?

Thanks,
Eric

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.