bug#13546: 24.2.92; Error(s) when sending emails

[Sebastien Vauban]

Eli,

Eli Zaretskii wrote:
>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Thu, 14 Feb 2013 12:01:54 +0100
>> 
>> Helm is starting updating (create the first process) after the
>> `requires-pattern' value of source, for locate it is 3, so when entering
>> the third char in pattern the process start, return the data through a
>> process-filter, then stop the process-filter (setq *filter t) and kill
>> the process. When you enter the 4th char, a new process is created,
>> killed and so on.
>
> The "kill process" part was an important clue, thanks.  Using that, I
> was able to re-create a situation similar to what happens for
> Sebastien.  I installed a few changes on the emacs-24 branch to
> prevent these problems, so I hope the next pretest will behave better.
>
> FWIW, the improved handling of subprocesses on the trunk avoids these
> problems altogether, at least in the scenario I used to re-create
> them.
>
> (There's still some strange issue with gnutls calls, as reported by
> Sebastien, which I'm still looking in.  Not sure if this is an
> additional problem or just "how things should work".)
>
>> This was just for info in case that help for debugging.
>
> Thanks, it helped.
>
> Btw, I'm surprised that helm starts an async subprocess, just to kill
> it after its output was collected.  Isn't this exactly what
> synchronous subprocesses are for?  What is the purpose of such a
> strange design? (except if you wanted to help find bugs in Emacs when
> async subprocesses are launched and killed at high frequency ;-)

IIUC, I guess the reason is not to block the user during typing: the fact that
Helm's locate is still collecting results does not hinder to type an extra
character to refined the search.

Best regards,
  Seb

-- 
Sebastien Vauban