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

[Eric Abrahamsen]

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.