From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Gnus generalized search, part II Date: Sat, 22 Apr 2017 15:50:16 -0700 Message-ID: <8737d0ukev.fsf@ericabrahamsen.net> References: <87zif930mt.fsf@ericabrahamsen.net> <87tw5hjnzr.fsf@hanan> <87mvb92er2.fsf@ericabrahamsen.net> <83efwkrhj1.fsf@gnu.org> <87inlw32ga.fsf@ericabrahamsen.net> <8337d0qxno.fsf@gnu.org> <87shl01bzb.fsf@ericabrahamsen.net> <83shl0p5pw.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492901499 30897 195.159.176.226 (22 Apr 2017 22:51:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 22 Apr 2017 22:51:39 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 23 00:51:35 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d23sM-0007up-FY for ged-emacs-devel@m.gmane.org; Sun, 23 Apr 2017 00:51:34 +0200 Original-Received: from localhost ([::1]:37150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d23sS-0003W1-4T for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2017 18:51:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d23ri-0003Vj-Ex for emacs-devel@gnu.org; Sat, 22 Apr 2017 18:50:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d23rf-0002Vt-Ba for emacs-devel@gnu.org; Sat, 22 Apr 2017 18:50:54 -0400 Original-Received: from [195.159.176.226] (port=55861 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d23rf-0002VA-4r for emacs-devel@gnu.org; Sat, 22 Apr 2017 18:50:51 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d23rU-0006jM-Hn for emacs-devel@gnu.org; Sun, 23 Apr 2017 00:50:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 66 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:OFbnGn8Z44yMstsEOr3WsoKvXeY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214230 Archived-At: Eli Zaretskii 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