From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Using incremental parsing in Emacs Date: Sun, 05 Jan 2020 15:27:28 -0500 Message-ID: References: <83blrkj1o1.fsf@gnu.org> <20200105141900.GA71296@breton.holly.idiocy.org> <83eewdg3vy.fsf@gnu.org> <835zhpg0fz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="242121"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: alan@idiocy.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 05 21:28:09 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ioCVM-0010qD-2H for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2020 21:28:08 +0100 Original-Received: from localhost ([::1]:45038 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioCVK-0001kQ-R6 for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2020 15:28:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54834) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioCUr-0001K5-LE for emacs-devel@gnu.org; Sun, 05 Jan 2020 15:27:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioCUp-0001ct-Tr for emacs-devel@gnu.org; Sun, 05 Jan 2020 15:27:36 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20706) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ioCUo-0001bi-DN; Sun, 05 Jan 2020 15:27:34 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5968C82BF6; Sun, 5 Jan 2020 15:27:33 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 22D03811A0; Sun, 5 Jan 2020 15:27:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1578256052; bh=UVGrksiHSO7rsarXhWaPe7ykKEqcXBEocyRKt3Lxoro=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=WS9NxflnY+4v3ymGIoUUdNq4tyMj8a0yOewc3cW654DwX+ya3crP85SesOP9wHgnc SXddOr0At/7aloxJkH0+Y5HaQ3Ndf/QbDMkD4rJPVnKirlz2XZMLaNBL8K1z+E3K2N xZAOqZ8YJ+TDvAbZBllRX7LExTiY4K4q7/1y/twP/vEECb+DKsPuPbeF8ho+O1iqWY 8r0CwSHzFSO20bXmm7J9z3IcpJ0U+6fjaoBnw4Hw+TEMO688wakRuOpLImV6BsjXHw kM3ah5p0m6GHtULTZkjrt1uNi5DTXt+37cpUme9VvAZAX5pK/QqoOSxT/Y2XOROoL6 T9ORwWKrBwGZA== Original-Received: from pastel (unknown [45.72.147.220]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D85CE120EB1; Sun, 5 Jan 2020 15:27:31 -0500 (EST) In-Reply-To: <835zhpg0fz.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Jan 2020 21:36:32 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.204.25.50 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243999 Archived-At: > That's exactly the issue: if we need to make a copy just to run the > parser asynchronously, then there's no advantage significant in having > such asynchronous processing inside the Emacs process, There can still be advantages depending on many other details. Another option is to give them direct access to the buffer, but only allow read-only access and impose some synchronization between the threads, e.g.: prepare_before_change could signal the concurrent threads and wait for them to acknowledge that they can't look at the buffer positions after START and then re-allow access past START when we finish the buffer modification or when we return to the command loop). Similarly, when buffer relocation takes place, we'd first signal to concurrent threads and wait for them to acknowledge that they've stopped accessing the buffer's content, and later re-signal them to let them know they can access it again. Stefan