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

Previous Next

Package: emacs;

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

Date: Tue, 8 Feb 2022 14:23:01 UTC

Severity: wishlist

Found in version 29.0.50

Full log


View this message in rfc822 format

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 53877 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: bug#53877: 29.0.50; [PATCH] async Gnus/nnml
Date: Thu, 10 Feb 2022 10:25:52 -0800
On 02/10/22 10:11 AM, Eric Abrahamsen wrote:
> On 02/10/22 10:02 AM, Manuel Giraud wrote:
>> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>>
>>> Manuel Giraud <manuel <at> ledu-giraud.fr> writes:
>>>
>>>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>>>
>>>>> Why can't you bind `nnmail-article-buffer' before calling the splitting
>>>>> function?
>>>>
>>>> I spoke too quickly. The idea was that with a temporay buffer I could
>>>> run multiple splitting in "parallel". But rebinding just *one* global
>>>> variable won't help much here.
>>>
>>> Are you sure? AFAIK this was Dick Chiang's approach to threading
>>> server updates: let-binding the value of `nntp-server-buffer' within
>>> the thread function. As far as I know it worked okay. The splitting
>>> function and code run within it will have a separate value of
>>> `nnmail-article-buffer'.
>>
>> I'm trying another approach: seek to the processes in the backend, don't
>> wait for them to end but instead attach sentinels for what's left to
>> do. Maybe it is not the best approach because Gnus seems to be heavily
>> stateful/serial.
>>
>> I'm not sure about binding in sentinels: do you think it would work as
>> binding in threads?
>
> Are you sure the original approach won't work? If you set
> `nnmail-article-buffer' locally within the thread function, it seems to
> work okay. Is this not workable:
>
> (defun test-threads-outer ()
>   (dolist (label (list "one" "two" "three"))
>     (make-thread (lambda () (test-threads-inner label)) label)))
>
> (defun test-threads-inner (label)
>   (let ((nnmail-article-buffer (format "nnmail-incoming-%s" label)))
>     (with-current-buffer (get-buffer-create nnmail-article-buffer)
>       (insert label))))
>
> That creates three separate buffers, named correctly, and holding the
> correct text.

Though in this simple example, the copies of the inner function are
actually still being executed consecutively, so maybe this doesn't prove
anything? I don't have much faith in my reasoning about threads.




This bug report was last modified 2 years and 281 days ago.

Previous Next


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