From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: make-thread with lambda form instead of function symbol Date: Mon, 17 Apr 2017 10:02:46 +0300 Message-ID: <83shl7ectl.fsf@gnu.org> References: <87efws9w3c.fsf@ericabrahamsen.net> <87bmrvu9am.fsf@ericabrahamsen.net> <87tw5n7l4g.fsf@ericabrahamsen.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492412583 1980 195.159.176.226 (17 Apr 2017 07:03:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Apr 2017 07:03:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 17 09:02:59 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 1d00gd-0000Pe-C2 for ged-emacs-devel@m.gmane.org; Mon, 17 Apr 2017 09:02:59 +0200 Original-Received: from localhost ([::1]:35150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d00gj-0001MN-Dg for ged-emacs-devel@m.gmane.org; Mon, 17 Apr 2017 03:03:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d00g2-0001MH-56 for emacs-devel@gnu.org; Mon, 17 Apr 2017 03:02:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d00fx-00080i-9t for emacs-devel@gnu.org; Mon, 17 Apr 2017 03:02:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d00fx-00080e-6Y; Mon, 17 Apr 2017 03:02:17 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4879 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1d00fw-00040m-6U; Mon, 17 Apr 2017 03:02:16 -0400 In-reply-to: <87tw5n7l4g.fsf@ericabrahamsen.net> (message from Eric Abrahamsen on Sun, 16 Apr 2017 20:45:19 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:214047 Archived-At: > From: Eric Abrahamsen > Date: Sun, 16 Apr 2017 20:45:19 -0700 > > >> (defun nnir-run-query (specs) > >> (let* ((results []) > >> (threads > >> (mapcar > >> (lambda (x) > >> (let* ((server (car x)) > >> (search-engine (nnir-server-to-search-engine server))) > >> (make-thread > >> (lambda () > >> (setq results > >> (vconcat > >> (nnir-run-search > >> search-engine > >> server > >> (cdr (assq 'nnir-query-spec specs)) > >> (cadr x)) > >> results)))))) > >> (cdr (assq 'nnir-group-spec specs))))) > >> (mapc #'thread-join threads) > >> results)) > >> > >> I'm testing with a single IMAP server query (ie, only one thread is > >> being created). The nnir-run-search function for the IMAP backend ends > >> up calling nnimap-send-command--> nnimap-wait-for-response--> > >> nnheader-accept-process-output--> accept-process-output, so I'm > >> expecting that's where the thread yields. In this chain of calls, where's the backend process started? > > error ("Attempt to accept output from process %s locked to thread %s", > > SDATA (proc->name), SDATA (XTHREAD (proc->thread)->name)); > > > > I guess that indicates you might be doing something wrong (though > > obviously Emacs shouldn't be crashing) > > So perhaps an existing process can't be "moved" to another thread? What does it mean "moved" in this context? How did you try to "move" a process to another thread? The ELisp manual says: ... by default a process is locked to the thread that created it. When a process is locked to a thread, output from the process can only be accepted by that thread. If you want to be able to accept process output from a thread other than the one which created it, you need to call set-process-thread. > But the segfault here seems to be coming from a borked attempt to > represent either the process or the thread as a string.... Yes. Should be fixed now. But my advice is to always give your thread meaningful names, as doing so will help you with debugging (unless you are very good in remembering the hex addresses of your thread objects ;-).