bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#53877: 29.0.50; [PATCH] async Gnus/nnml


From: Eric Abrahamsen
Subject: bug#53877: 29.0.50; [PATCH] async Gnus/nnml
Date: Thu, 10 Feb 2022 10:25:52 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

On 02/10/22 10:11 AM, Eric Abrahamsen wrote:
> On 02/10/22 10:02 AM, Manuel Giraud wrote:
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>>>
>>>> Lars Ingebrigtsen <larsi@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]