From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Concurrency via isolated process/thread Date: Mon, 24 Jul 2023 10:09:50 +0000 Message-ID: <875y6939jl.fsf@localhost> References: <871qhnr4ty.fsf@localhost> <83sfa1gjns.fsf@gnu.org> <87r0plxbep.fsf@localhost> <83ilawhpi6.fsf@gnu.org> <87zg48apwr.fsf@localhost> <83edljg8ub.fsf@gnu.org> <87o7knbxr7.fsf@localhost> <838rbrg4mg.fsf@gnu.org> <87ilavbvdr.fsf@localhost> <834jmffvhy.fsf@gnu.org> <878rbrbmwr.fsf@localhost> <83fs5zecpo.fsf@gnu.org> <87351zbi72.fsf@localhost> <83351yevde.fsf@gnu.org> <87cz12ad2w.fsf@localhost> <83a5w6cwdr.fsf@gnu.org> <87pm518m0g.fsf@localhost> <83o7kl9tyj.fsf@gnu.org> <874jmd89us.fsf@localhost> <878rb53dkj.fsf@localhost> <87wmyp1vr9.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14618"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 24 12:10:47 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 1qNsWd-0003Y2-01 for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 12:10:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNsVh-0007fj-UQ; Mon, 24 Jul 2023 06:09:52 -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 1qNsVc-0007fO-8N for emacs-devel@gnu.org; Mon, 24 Jul 2023 06:09:45 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNsVY-0000WZ-KL for emacs-devel@gnu.org; Mon, 24 Jul 2023 06:09:42 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 085F624002B for ; Mon, 24 Jul 2023 12:09:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690193378; bh=5wvTsu0j55S724znEzYVoGCD1HNCNOkae87cehJtDWM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=HXaH4HPEA60ehdYExPkX4z1vEo9YJYvubS5ZCrHpexs8bu0ljO/bt2iNsoPyeBwKJ kzVz49mRAtLZ0bNbsqgLIWQFgoGxPcjlWOuQVhZksVocWwfkkJHqHG7MOJonEY6f7f Y/jVttbFW8d7uj+m1hIuo0dOGTfw8WtO8fY6SFjX86TzYFwnNJ5oWsgSpbqZtFqS2C QiQkk4luFfnfNKQxWAxkOPihp5isCcQSIHwN122fRDjxzSPnzbCMtqxx19L8olXWGF 7U+VHCkyunmtJ1mbDVzukxWwkDw4oiKLhDE/u3RELmcnYBakfFHUoZK4h2Pw6I9462 LRH/fGQYPkA6w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R8bVn0Stwz6twX; Mon, 24 Jul 2023 12:09:36 +0200 (CEST) In-Reply-To: <87wmyp1vr9.fsf@yahoo.com> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:308047 Archived-At: Po Lu writes: >> Would it be acceptable to convert buffer PT, BEGV, and ZV into >> thread-local for current cooperative threads? > ... > But how much do you want to slow down accesses to PT in the future, when > multiple threads will run simultaneously? Operations that use and > modify PT are essentially the bread and butter of Emacs, and as a result > accesses to PT must be very fast. I do not plan to slow down access to PT. The basic idea is to have #define PT (current_thread->m_pt + 0) #define PT_BYTE (current_thread->m_pt_byte + 0) Basically, use thread object slot instead of buffer object slot to store point and restriction. This will not cause any performance degradation and allow multiple points in the same buffer. What may be slightly slower is setting/getting points in other (not current) buffers. We will need to store point and restriction history for each thread. Searching this history will scale with the number of buffers that have been current previously during thread execution (though we may use hash table if necessary). However, accessing and changing point in buffer that is not current is not very common. AFAIU, it is done in (1) read operation when reading from stream represented by a buffer; (2) when switching buffers when we need to transfer current PT to history for current buffer and retrieve PT from history for the buffer that will become current. > In addition to that, we already have separate window and buffer > points. It would confound users even more to add a third kind of > object with its own point to the mix. I propose to remove buffer points completely and use thread points instead. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at