[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.
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, (continued)
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Manuel Giraud, 2022/02/09
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Lars Ingebrigtsen, 2022/02/09
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Manuel Giraud, 2022/02/09
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Lars Ingebrigtsen, 2022/02/09
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Manuel Giraud, 2022/02/09
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Lars Ingebrigtsen, 2022/02/09
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Manuel Giraud, 2022/02/09
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Eric Abrahamsen, 2022/02/09
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Manuel Giraud, 2022/02/10
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Eric Abrahamsen, 2022/02/10
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml,
Eric Abrahamsen <=
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Eli Zaretskii, 2022/02/10
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Eric Abrahamsen, 2022/02/10
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Manuel Giraud, 2022/02/11
- bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Eric Abrahamsen, 2022/02/11
bug#53877: 29.0.50; [PATCH] async Gnus/nnml, Lars Ingebrigtsen, 2022/02/09