From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Akira Kyle Newsgroups: gmane.emacs.devel Subject: Re: "Asynchronous Requests from Emacs Dynamic Modules" Date: Sun, 01 Nov 2020 13:15:43 -0700 Message-ID: <86a6w0omts.fsf@akirakyle.com> 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> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9523"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.13; emacs 28.0.50 Cc: p.stephani2@gmail.com, emacs-devel@gnu.org, yyoncho@gmail.com, monnier@iro.umontreal.ca, all_but_last@163.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 01 21:16:24 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 1kZJm3-0002L0-KV for ged-emacs-devel@m.gmane-mx.org; Sun, 01 Nov 2020 21:16:23 +0100 Original-Received: from localhost ([::1]:36198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZJm2-0004DH-Mi for ged-emacs-devel@m.gmane-mx.org; Sun, 01 Nov 2020 15:16:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52374) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZJlU-0003iA-Qt for emacs-devel@gnu.org; Sun, 01 Nov 2020 15:15:48 -0500 Original-Received: from mail-ot1-f54.google.com ([209.85.210.54]:46489) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZJlS-0008UE-I1; Sun, 01 Nov 2020 15:15:48 -0500 Original-Received: by mail-ot1-f54.google.com with SMTP id g19so1273392otp.13; Sun, 01 Nov 2020 12:15:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=vyUG1fFRj5CuCvV7/tio/S62ZyAiZCBpOb0ffiG4C5w=; b=NITiaPRvIN3ZMPjL/Zp5KP2nfOGtB6FtXjK5q+x+4FaVHNBzzu7QpJDlD+Ajc/06eZ mohbwVpa/cyjK5QQ3Q/OpY7xOJfuMLPkmOuBYx1dSqq6iW07hrMAeV9RIqJMztpRayxg U+t1XmbKZo+RuHngnQ383e0v+0gJGUrQ3YOGMXRV0wGNQs/8o9qefTq28+qiAxYWx69+ +72946pkHuG8y1ZFqa8F+YH5m24c5RnVOy71SDngzkBAFTHbZxTHGBVdGtYYpgZ8Vlxf I+rDEOh0Y3pYti8+CvMUT1BMbwOblKKUetA6s9vWjxaDZ3MLsMrhRXJt8eu+bya1ydTS hiOQ== X-Gm-Message-State: AOAM530Slx4Y08WFYdiUQ91EPUTSyhuIZNBQiFoZZbH2nai70nqu7ypi 2GTI/3rMGdSyk3SaM0jYmSU= X-Google-Smtp-Source: ABdhPJwuR6HllEy9DFsGMbNNgpsKa7Vo6kiTXOVmV2BuSqkNILTwXxoFQpLW20AEMnvdp227Km0FCw== X-Received: by 2002:a05:6830:1254:: with SMTP id s20mr9273989otp.314.1604261745095; Sun, 01 Nov 2020 12:15:45 -0800 (PST) Original-Received: from lore (c-67-162-131-131.hsd1.co.comcast.net. [67.162.131.131]) by smtp.gmail.com with ESMTPSA id q7sm3023393oig.42.2020.11.01.12.15.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Nov 2020 12:15:44 -0800 (PST) In-reply-to: <837dr5exsq.fsf@gnu.org> Received-SPF: pass client-ip=209.85.210.54; envelope-from=aikokyle@gmail.com; helo=mail-ot1-f54.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/01 15:15:45 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:258607 Archived-At: On Sun, Nov 01, 2020 at 11:28 AM, Eli Zaretskii wrote: >> It seems the lisp threading functionality is still pretty beta >> quality. Have the data races that Chris Wellons mentions here >> [1] >> ever been addressed? > > It's hard to tell, because that blog has no specifics, just a > broad > accusation. It is also quite old. > >> It looks like it's mostly just exposing the pthread interface. > > That's simply not true. It _uses_ pthreads to start and manage > threads, and to implement mutexes, condvars, etc. But if you > look > closely at the level of thread.c (_not_ systhread.c), you will > see > something very different from a typical pthreads application. 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. >> What is the use case for the current lisp threads given the >> severe >> limitation that only will ever run at a time and the >> constraints the >> cooperative nature puts on when threads can switch? > > 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. Do you know of anyone who uses it? I'd be very interested in seeing some examples how to successfully use it. 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. [1] https://github.com/skeeto/emacs-aio