From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: "Asynchronous Requests from Emacs Dynamic Modules" Date: Sat, 31 Oct 2020 22:18:53 +0200 Message-ID: <831rhegnde.fsf@gnu.org> References: <86imarfldb.fsf@akirakyle.com> <86y2jn9j70.fsf@163.com> <83pn4y96ut.fsf@gnu.org> <83lffmhi5y.fsf@gnu.org> <83h7qahe03.fsf@gnu.org> <86ft5ufb95.fsf@akirakyle.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39356"; mail-complaints-to="usenet@ciao.gmane.io" Cc: p.stephani2@gmail.com, emacs-devel@gnu.org, yyoncho@gmail.com, monnier@iro.umontreal.ca, all_but_last@163.com To: Akira Kyle Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 31 21:20:22 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kYxMM-000A8f-20 for ged-emacs-devel@m.gmane-mx.org; Sat, 31 Oct 2020 21:20:22 +0100 Original-Received: from localhost ([::1]:43122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYxML-0002Qz-4t for ged-emacs-devel@m.gmane-mx.org; Sat, 31 Oct 2020 16:20:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55616) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYxLD-0001wx-Bf for emacs-devel@gnu.org; Sat, 31 Oct 2020 16:19:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43237) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYxLA-0007FO-Pu; Sat, 31 Oct 2020 16:19:08 -0400 Original-Received: from [176.228.60.248] (port=4296 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kYxLA-0004DG-A1; Sat, 31 Oct 2020 16:19:08 -0400 In-Reply-To: <86ft5ufb95.fsf@akirakyle.com> (message from Akira Kyle on Sat, 31 Oct 2020 13:25:58 -0600) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258590 Archived-At: > From: Akira Kyle > Cc: yyoncho , all_but_last@163.com, emacs-devel@gnu.org, > Stefan Monnier , Philipp Stephani > > Date: Sat, 31 Oct 2020 13:25:58 -0600 > > 1) Chris Wellon's solution in the article I linked using the > SIGUSR1 signal which Emacs handles in the event queue notify the > running Lisp Thread that it should call back into module > functions. This idea could be expanded to allow modules to define > their own events and lisp handlers that will respond to them. A terrible design, if you ask me. Reminds me how timers worked in Emacs long ago: we had an external program which would periodically deliver a signal to Emacs. We switched off of that to what we have now, for good reasons. And please keep in mind that doing anything non-trivial from a signal handler is inherently unsafe. > 2) Stefan's and Philipp's proposal of using the process interface > with file descriptors to pipes and perhaps `process-filter` to > notify the Lisp Thread that it should call back into the module > functions. This is the way to go, IMO. This is how Emacs itself handles async events, so the infrastructure for doing this, both in C and in Lisp, already exists, and is mature. All you need is use it. > 3) yyoncho's proposal to use the lisp threading interface, > specifically condition variables to allow dynamic modules to > `condition-notify`. This is unworkable within the current design of Lisp threads. condition-notify releases the global lock, something that under the current design cannot be done at an arbitrary time, because it could cause two threads run in parallel. > I think the most natural solution would be a dynamic module > interface that allows grabbing and releasing Lisp's global thread > lock. I encourage you to study how threading works in Emacs (the code is in thread.c). I'm sure you will see right away why this cannot be done without a complete redesign of how switching threads works. There's no way of interrupting a running Lisp thread in an arbitrary place and switching to another thread.