help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Async process sentinel running exclusively in main thread?


From: Félix Baylac Jacqué
Subject: Re: Async process sentinel running exclusively in main thread?
Date: Tue, 21 Jun 2022 08:03:21 +0200

> Sentinel runs when Emacs receives SIGCHLD due to the process's demise.
> And on Posix systems, signals in Emacs are always delivered to the
> main thread, because doing that in a non-main thread is unsafe (the
> thread could be exiting, for example).

Thanks for the explanation, it makes sense now!

> Make the process output something, and wait on its output?

Aha. It was indeed the way to go, thanks for this really useful advice!

For posterity's sake, the following snippet ended up doing the trick.
h--call-git-in-dir being a function spinning up the asynchronous process here.

--8<---------------cut here---------------start------------->8---
(defun h--tests-init-fake-git-repo (dir)
  "Create a dummy git repo at DIR.

If DIR doesn't exist, we create it first."
  (let* ((d (file-name-as-directory dir))
         (exit-code 0)
         (git-process
          (progn
            (make-directory d t)
            (h--call-git-in-dir d
                                (lambda (ec) (setq exit-code ec))
                                "init"))))
    (progn
      (unless (file-directory-p d) (make-directory d t))
      ;; ERT does not handle async processes gracefully for the time
      ;; being. Blocking and waiting for the git process to exit
      ;; before moving on.
      (while (accept-process-output git-process)))))
--8<---------------cut here---------------end--------------->8---

> Btw, Emacs has a way of causing a process to be dedicated to a thread
> (which AFAIU you didn't do in your code).

I was relying on the implicit behavior described in the section 39.9.5
of the Elisp manual:

> by default a process is locked to the thread that created it.

I just checked this assertion with:

--8<---------------cut here---------------start------------->8---
(defun test-make-process ()
  (let* ((run-async-process
          (lambda ()
            (progn
              (message (format "run-async-process thread: %s" 
(prin1-to-string(current-thread))))
              (make-process
               :name "dummy-async-subprocess"
               :buffer "sleep-buf"
               :command '("sleep" "5"))))))
    (progn
      (setq process (make-thread run-async-process))
      (message (format "Main thread: %s" (prin1-to-string main-thread)))
      (message (format "Process thread: %s" (prin1-to-string process))))))

(test-make-process)
--8<---------------cut here---------------end--------------->8---

Message output:

--8<---------------cut here---------------start------------->8---
Main thread: #<thread 0x9ccc60>
Process thread: #<thread 0x631bd40>
run-async-process thread: #<thread 0x631bd40>
--8<---------------cut here---------------end--------------->8---

It does seem like the process is indeed locked to the thread that created
it (i.e. not the main thread in that example).

I guess that explicitly locking the process to a particular thread via
set-process-thread wouldn't hurt and would maybe future-proof a bit more
in case that implicit assertion breaks sometime in the future.

Again, thanks a lot for this enlightening explanation and useful advice!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]