Re: [RFC] Gnus generalized search, part II

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Noam Postavsky <npostavs@users.sourceforge.net> writes:

> On Sat, Apr 22, 2017 at 11:08 AM, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
>> I'm still trying to get a correct mental model of how all this is
>> working. I assume that, if I gather the threads using:
>>
>> (mapc #'thread-join threads)
>>
>> None of the threads ever become the "current thread",
>
> Wouldn't thead-join stop the current thread, and then whichever thread
> runs next (probably one of the ones in `threads') would become the
> current thread?

Ah, of course! Yeesh, this is taking a while to wrap my brain around.

Eli Zaretskii <eliz@gnu.org> writes:

> But what _is_ the right thing?
>
> I asked the question because I really would like to know what would
> you want/expect to be the effect of C-g on the active threads?  It's
> not a rhetoric question.  Can you please humor me?

Okay! Sorry... Basically we're sending search queries to multiple
servers, and using threads to make the external processes asynchronous.
C-g would come into play when one or more of those processes hangs or is
slow, and the user loses patience and wants to quit. The desired result
would be that whichever thread we're currently waiting on gets killed,
and the other threads continue. Ideally there would be a message noting
which search process was abandoned, which is another reason to use
condition-case.

Ugh, this is hurting my brain. Here's the code skeleton:

(let* ((results "")
       (threads
	(mapcar
	 (lambda (thing)
	   (make-thread
	    (lambda ()
	      (let ((proc (start-process name buf thing-program)))
		(accept-process-output proc)
		(with-current-buffer buf
		 (setq results
		       (concat (buffer-string) results)))))))
	 '(thing1 thing2))))
  (mapc #'thread-join threads))

accept-process-output is given no timeout. So when we hit the first
`thread-join', we wait for the first accept-process-output to return
completely, putting all its output in its process buffer. While it's
doing that, output from the second and third thread processes is also
arriving on the wire, but it's being buffered in C code or in the
process itself or in some other special non-Lisp place (I'm making this
part up, I have no idea). Assuming the three processes take the same
amount of time, the second and third `thread-join's should finish very
quickly, because all they have to do is dump their output from wherever
it's being held into their respective process buffers, and then concat
the buffer strings into the result.

Is that actually what happens?

I'm trying to think about what would happen if we looped the
`accept-process-output' on say a half-second timeout. When the first
`thread-join' is called, does it mean all three processes would start
getting half-second opportunities to write process output into their
output buffers? Or would the second and third threads not get to do
their `accept-process-output' calls at all until they were joined?
Here's where I get confused.

Realistically, the user would be unlikely to quit unless one of the
processes was taking a very long time, at which point that would be the
only running thread, and probably the right thing would happen.

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 22 Apr 2017 18:17:47 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > Is (accept-process-output 0) the same as (accept-process-output
>> > nil)?
>> 
>> Yes.
>
> Sorry, I've misread the code.  Zero means don't wait at all, even if
> process output is not available.

Good to know, thanks. Actually, in a second I'll do a patch to add that
to the docstring, that's useful information.

Eric