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

[Eric Abrahamsen]

Eli Zaretskii <address@hidden> writes:

>> 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.

Okay that certainly explains it -- I hadn't found that part of the
manual. The IMAP process in question was long-running, created well
before this thread was, so I was doing exactly the wrong thing. (All I
meant by "move" was starting the process in one thread, and accepting
its output in another.)

>> 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 ;-).

Segfault's gone, thank you. Now to figure out where to stick the call to
`set-process-thread'.

And thanks for the "thread apply all bt" trick, I'll remember that.

Eric