From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Mon, 04 Sep 2023 16:08:50 +0200 Message-ID: <87v8cqowst.fsf@dataswamp.org> References: <87ledwx7sh.fsf@yahoo.com> <877cpfybhf.fsf@yahoo.com> <873503y66i.fsf@yahoo.com> <87fs3ur9u8.fsf@dataswamp.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="32102"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:fe/Ybjz5mj/GtA/VT29cfTVeSgo= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 04 17:18:28 2023 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 1qdBLQ-00089W-BZ for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Sep 2023 17:18:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdBKf-0000QE-Gh; Mon, 04 Sep 2023 11:17:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdAGF-0006r4-Em for emacs-devel@gnu.org; Mon, 04 Sep 2023 10:09:04 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdAGC-0001jb-UL for emacs-devel@gnu.org; Mon, 04 Sep 2023 10:09:03 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qdAGA-0008EY-Tr for emacs-devel@gnu.org; Mon, 04 Sep 2023 16:08:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 04 Sep 2023 11:17:39 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310080 Archived-At: Rudolf Schlatte wrote: > So race conditions resulting from multiple threads modifying > Lisp data structures concurrently are entirely the > programmer's responsibility in SBCL, to be handled by using > the provided standard tools (mutexes, locks, condition > variables etc). So if you create an application in CL, you > have to check that the libraries you use are thread-safe. > For Emacs, where multiple applications and libraries are > assembled into an editor by the end user, instead of > a programmer creating one application to be run in isolation > in an SBCL image, I believe this approach will not work. Since Lisp is and should be the EVERYTHING language, it is all well and good that the programmer can do that, however - we should aim at the other end of everythingness as well - namely, to have Elisp do that seamlessly and on the fly so that multicored Elisp in execution would happen whenever beneficial also (especially) when executing normal, including all existing for that matter, Elisp code. However, as a first step toward that, we would indeed welcome specific constructs, e.g. (let-para ((one (...)) (two (...)) ) (compute one two) ) Where 'para' is for "parallel" and would work as this, 'one' would be computed on CPU core 1, 'two' on CPU core 2 - starting simultaneously and executing in parallel as you might have guessed - and the body, in this case "compute", would be evaluated when both are done. How would you do that? At least we don't have to bother with let-para* LOL -- underground experts united https://dataswamp.org/~incal