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 12:25:12 -0700 Message-ID: <87shl01bzb.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492889152 737 195.159.176.226 (22 Apr 2017 19:25:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 22 Apr 2017 19:25:52 +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 Sat Apr 22 21:25:49 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 1d20fE-00006O-Tl for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2017 21:25:49 +0200 Original-Received: from localhost ([::1]:36644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d20fK-0002tn-SN for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2017 15:25:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d20fF-0002ti-8k for emacs-devel@gnu.org; Sat, 22 Apr 2017 15:25:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d20fC-0003kl-2Y for emacs-devel@gnu.org; Sat, 22 Apr 2017 15:25:49 -0400 Original-Received: from [195.159.176.226] (port=36398 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d20fB-0003kd-Rj for emacs-devel@gnu.org; Sat, 22 Apr 2017 15:25:45 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d20f3-0008Gv-Nv for emacs-devel@gnu.org; Sat, 22 Apr 2017 21:25:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 94 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:GB/92ICCGFj+0mjpVypStRqo75s= 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:214222 Archived-At: Noam Postavsky writes: > On Sat, Apr 22, 2017 at 11:08 AM, Eric Abrahamsen > 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 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 writes: >> Date: Sat, 22 Apr 2017 18:17:47 +0300 >> From: Eli Zaretskii >> 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