[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Gnus generalized search, part II

From: Eric Abrahamsen
Subject: Re: [RFC] Gnus generalized search, part II
Date: Sat, 22 Apr 2017 15:50:16 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> 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

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]