[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
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
- [RFC] Gnus generalized search, part II, Eric Abrahamsen, 2017/04/21
- Re: [RFC] Gnus generalized search, part II, Andrew Cohen, 2017/04/21
- Re: [RFC] Gnus generalized search, part II, Eric Abrahamsen, 2017/04/22
- Re: [RFC] Gnus generalized search, part II, Eli Zaretskii, 2017/04/22
- Re: [RFC] Gnus generalized search, part II, Eric Abrahamsen, 2017/04/22
- Re: [RFC] Gnus generalized search, part II, Eli Zaretskii, 2017/04/22
- Re: [RFC] Gnus generalized search, part II, Eli Zaretskii, 2017/04/22
- Re: [RFC] Gnus generalized search, part II, Eric Abrahamsen, 2017/04/22
- Re: [RFC] Gnus generalized search, part II, Eli Zaretskii, 2017/04/22
- Re: [RFC] Gnus generalized search, part II,
Eric Abrahamsen <=
- Re: [RFC] Gnus generalized search, part II, Eric Abrahamsen, 2017/04/30
- Re: [RFC] Gnus generalized search, part II, Stephen Leake, 2017/04/24
- Re: [RFC] Gnus generalized search, part II, Eli Zaretskii, 2017/04/26
- Re: [RFC] Gnus generalized search, part II, Noam Postavsky, 2017/04/22
Re: [RFC] Gnus generalized search, part II, Eli Zaretskii, 2017/04/22
Re: [RFC] Gnus generalized search, part II, Lars Ingebrigtsen, 2017/04/22