From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rudolf Schlatte Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Mon, 04 Sep 2023 07:49:08 +0200 Message-ID: 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; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37944"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:XETig7vMAo+VpMxlLN2HX9QJVHM= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 04 12:48:10 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 1qd77o-0009bj-Mb for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Sep 2023 12:48:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qd775-0001Kj-Vc; Mon, 04 Sep 2023 06:47:23 -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 1qd2TJ-0007yA-Pc for emacs-devel@gnu.org; Mon, 04 Sep 2023 01:50: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 1qd2TH-00011H-41 for emacs-devel@gnu.org; Mon, 04 Sep 2023 01:50:01 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qd2TF-00032r-5x for emacs-devel@gnu.org; Mon, 04 Sep 2023 07:49:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ 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 06:47:21 -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:310060 Archived-At: Emanuel Berg writes: > As for the multicore processing thing, I wonder how they > did that? And why can't we do that as well with Elisp? That is answered by the SBCL manual. The first sentence of http://sbcl.org/manual/index.html#Threading says: "SBCL supports a fairly low-level threading interface that maps onto the host operating system’s concept of threads or lightweight processes." 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.