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: Mon, 02 Nov 2020 17:22:12 +0200 Message-ID: <83ft5reqcb.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> <831rhegnde.fsf@gnu.org> <86d00yexw7.fsf@akirakyle.com> <837dr5exsq.fsf@gnu.org> <86a6w0omts.fsf@akirakyle.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36391"; 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 Mon Nov 02 16:23:20 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 1kZbfz-0009CM-R5 for ged-emacs-devel@m.gmane-mx.org; Mon, 02 Nov 2020 16:23:19 +0100 Original-Received: from localhost ([::1]:41884 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZbfy-0001OS-PZ for ged-emacs-devel@m.gmane-mx.org; Mon, 02 Nov 2020 10:23:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZbf7-0000Su-Hs for emacs-devel@gnu.org; Mon, 02 Nov 2020 10:22:25 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48088) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZbf5-0007hG-V6; Mon, 02 Nov 2020 10:22:23 -0500 Original-Received: from [176.228.60.248] (port=4281 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kZbf5-0002HR-AT; Mon, 02 Nov 2020 10:22:23 -0500 In-Reply-To: <86a6w0omts.fsf@akirakyle.com> (message from Akira Kyle on Sun, 01 Nov 2020 13:15:43 -0700) 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:258629 Archived-At: > From: Akira Kyle > Cc: yyoncho@gmail.com, all_but_last@163.com, emacs-devel@gnu.org, > monnier@iro.umontreal.ca, p.stephani2@gmail.com > Date: Sun, 01 Nov 2020 13:15:43 -0700 > > Sorry I meant not that it directly exposes pthreads but that its > interface is modeled off of pthreads (i.e. mutexes, condition > variables), but lisp should really have some higher level > interface to parallel and concurrent execution (like Python's > multiprocessing or asyncio interface). Perhaps it can be built on > top of the current lisp threading interface, but it seems there > may be some limitations that make that difficult. Maybe it can, but I'm not sure I see the need yet. What exactly is wrong with the existing primitives? After all, the Lisp threads _are_ threads, so basic thread operations for them do make sense. > > The main use case is to allow you to write one or more background > > Lisp programs that go about their job while a foreground command > > lets the user interact normally with Emacs. > > Right, but due to the global lock this only allows for concurrent > execution, and due to the cooperative nature needing one to > explicitly yield execution for threads to switch, it seems like in > reality it would be very cumbersome to work with. Emacs yields automatically when it waits for input, so the idea was that it wouldn't be cumbersome. > Do you know of anyone who uses it? I'd be very interested in seeing > some examples how to successfully use it. Michael Albinus did, I think you can see his work on a branch in our Git repository. > I think libraries like emacs-aio [1] accomplish the same thing but > with a much easier to use interface. By using (run-at-time 0 nil > callback args) they accomplish a sort of "green threading" that > doesn't actually need any sort of pthread support or the > associated issues with ensuring atomicity with the interpreter. It > would be great to have something like this built in. run-at-time is our poor man's threading from years ago; Lisp threads were supposed to make such background applications easier to implement.