Re: [RFC] Gnus generalized search, part II

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> Ideally there would be a message noting which search process was
>> abandoned, which is another reason to use condition-case.
>
> You mean condition-case in the thread function?

My original assumptions about how things work have mostly turned out
wrong. So sure, inside the thread function! I need to set up some dummy
shell programs and test this.

>> 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).
>
> Not exactly.  While the first thread waits for output, we let some
> other thread run, until that other thread starts waiting as well.  The
> first thread whose wait is over will become active again, because the
> main thread is waiting for thread-join.  IOW, the main thread waits in
> thread-join, whereas the other threads wait in accept-process-output.
> I think.

[...]

> The first thread runs when the first thread-join is called by the main
> thread.  The second thread gets run when the first thread calls
> accept-process-output.  Etc. with the other threads.

Okay so this was a key point of confusion for me, and I think I've
finally got it, thank you. I'd misunderstood what Noam was telling me
about the scope of the "results" variable: I thought it needed to be
visible because the thread function started execution immediately, but
he was telling me it needed to be visible because it was captured in the
thread-function closure. Execution doesn't start until the main thread
yields.

So under normal circumstances (processes that take a non-negligible
amount of time to return) we'd do the first thread-join, then all three
threads would end up waiting in accept-process-output. What happens next
could depend on whether thread two or three came out of
accept-process-output before thread one did. As you say:

> I think there could be a problem if a thread finishes accepting its
> output before its thread-join was called.

It shouldn't be too hard to create this test condition.

>> 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.
>
> The problematic scenario is when the main thread gets the C-g.  I'm
> not sure this couldn't happen in your setup.

That could happen if the quit came between two of the calls to
`thread-join', yes? I suppose I could do something with inhibit-quit
around the mapc, but that's getting ahead of myself a bit.

Thanks again,
Eric