From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?F=C3=A9lix?= Baylac =?utf-8?Q?Jacqu=C3=A9?= Newsgroups: gmane.emacs.help Subject: Re: Async process sentinel running exclusively in main thread? Date: Tue, 21 Jun 2022 08:03:21 +0200 Message-ID: <878rpq5z9y.fsf@alternativebit.fr> References: <8735fzbu7r.fsf@alternativebit.fr> <83edzjmvcr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12842"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 21 08:06:48 2022 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o3X2G-00038N-5h for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 21 Jun 2022 08:06:48 +0200 Original-Received: from localhost ([::1]:45914 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3X2E-0003sf-KY for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 21 Jun 2022 02:06:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51346) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3Wz2-0003WC-Gg for help-gnu-emacs@gnu.org; Tue, 21 Jun 2022 02:03:31 -0400 Original-Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]:45095) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3Wz0-00066j-BH for help-gnu-emacs@gnu.org; Tue, 21 Jun 2022 02:03:28 -0400 Original-Received: (Authenticated sender: felix@alternativebit.fr) by mail.gandi.net (Postfix) with ESMTPSA id 0135EE0002 for ; Tue, 21 Jun 2022 06:03:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alternativebit.fr; s=gm1; t=1655791402; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FYcBRyTSvSMcVfDFrK4Tu9bmJGpq7mQe3UXpEhVNV/s=; b=ZgV6xKARCjuv0mXpYOvRMjHCn2FGVd2aZvkKwAt3IkCbjAp7rAos8k6EWzB69DjuudP9aY 96ts9vayNhcdYTr7RlrSI2xsf8LCPoLXzQCCoVuYtyokKs4Ld5GN61YHjT2pt7EtJsNsEF cjnvaYPif3OsJG6VC9VGzMlhtL4k2YQzy7Jg43MbydoLNJLmNYtOhb42HvTQdopskHjZe4 oic/ZvMipu5osbaTuLPwjuhZEbSMkyHV45W39DXkd9k4bZB9yodQ/iePScCtHodo97WuTw dliyrl+O/UEMiezM2J+eEFCL1NLjsdDia+Q0WBjdoYuNlnrAH28BJ0vjFt4Gig== In-Reply-To: <83edzjmvcr.fsf@gnu.org> Received-SPF: pass client-ip=2001:4b98:dc4:8::224; envelope-from=felix@alternativebit.fr; helo=relay4-d.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:137948 Archived-At: > 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: # Process thread: # run-async-process thread: # --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!