Re: make-thread with lambda form instead of function symbol

[Eli Zaretskii]

> From: Eric Abrahamsen <address@hidden>
> 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 ;-).