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: How to add pseudo vector types Date: Wed, 21 Jul 2021 14:26:10 +0300 Message-ID: <8335s76h7x.fsf@gnu.org> References: <83h7gw6pyj.fsf@gnu.org> <45EBF16A-C953-42C7-97D1-3A2BFEF7DD01@gmail.com> <83y2a764oy.fsf@gnu.org> <83v95b60fn.fsf@gnu.org> <00DD5BFE-D14E-449A-9319-E7B725DEBFB3@gmail.com> <83r1fz5xr9.fsf@gnu.org> <1AAB1BCC-362B-4249-B785-4E0530E15C60@gmail.com> <83czri67h0.fsf@gnu.org> <46BBFF88-76C3-4818-8805-5437409BEA93@gmail.com> <83wnpq46uk.fsf@gnu.org> <533BD53B-4E85-4E9E-B46A-346A5BBAD0F5@gmail.com> <258CB68D-1CC1-42C8-BDCD-2A8A8099B783@gmail.com> <1a776770-50b7-93cd-6591-c9a5b3a56eb8@gmail.com> <83lf654dhk.fsf@gnu.org> <2524265f-60c7-24f5-b9f4-98447c91acab@gmail.com> 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="11174"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 21 13:27:51 2021 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 1m6AOE-0002eg-7A for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Jul 2021 13:27:50 +0200 Original-Received: from localhost ([::1]:36156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6AOC-0006gC-6o for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Jul 2021 07:27:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6AMf-0005uT-67 for emacs-devel@gnu.org; Wed, 21 Jul 2021 07:26:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44562) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6AMe-0001l2-FS; Wed, 21 Jul 2021 07:26:12 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2872 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6AMe-0001G4-0b; Wed, 21 Jul 2021 07:26:12 -0400 In-Reply-To: <2524265f-60c7-24f5-b9f4-98447c91acab@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Tue, 20 Jul 2021 16:36:42 -0400) 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:271406 Archived-At: > Cc: emacs-devel@gnu.org > From: Clément Pit-Claudel > Date: Tue, 20 Jul 2021 16:36:42 -0400 > > Thanks for the detailed reply. > > On 7/17/21 3:16 AM, Eli Zaretskii wrote: > > When Emacs moves or enlarges/shrinks the gap, that affects the entire > > buffer text after the gap, regardless of where the gap is. So it will > > affect the TS reader if it reads stuff after the gap. > > Doesn't enlarging the gap require allocating a new buffer and copying data to it? Not necessarily. First, gap could be enlarged for reasons other than growing buffer text as a whole. And even if we must grow buffer text, a good memory-allocation system will many times resize the existing memory block before it allocates another.. > If so it wouldn't affect the TS reader. Not true, in general. When a new block is allocated by the OS/libc, the old one is generally invalid and cannot be accessed. In many cases, the old block could be unmapped from the program's address space, in which case accessing it will segfault. > Moving is indeed trickier, that's what I referred to as "limited contention". We move the gap quite a lot. > >> You do need to be careful to not read the garbage data from the gap, but otherwise seeing stale or even inconsistent data from the parser thread shouldn't be an issue, since tree-sitter is supposed to be robust to bad parses. > > > > What would be the purpose of calling the parser if we know in advance > > it will fail when it gets to the "garbage" caused by async access to > > the buffer text? > > It won't fail, will it? "Fail" in the sense that it will be able to process only a small portion of buffer text before it gets to garbage. > > And what do you want the code which requested parsing do while the > > parse thread runs? The requesting code is in the main thread, so if > > it just waits, you don't gain anything. > > You'd have the parser running continuously in the background, every time there is a change. When a piece of code requests a parse it blocks and waits, but presumably for not too long because a very recent previous parse means that the blocking parse is fast. Well, you cannot safely/usefully parse the buffer "continuously in the background", for the reasons explained above, because Lisp programs change buffer text quite a lot. > > I don't understand what could recording the gap solve. The stuff in > > the gap is generally garbage, and can easily include invalid multibyte > > sequences. I don't think it's a good idea to pass that to TS. Also, > > recording the gap changes in the main thread and accessing that > > information from a concurrent thread again opens a window for races, > > and requires synchronization. > > This list of gap changes wouldn't be accessed concurrently: you would (message-)pass a copy of it to the parser thread every time it starts a new parse. I still don't see the point. Can you describe in more detail what would you suggest doing with the list of gap changes? Just take a specific example of a small set of gap changes and tell how to use that.