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: Tue, 25 Jul 2023 04:28:40 +0000 Message-ID: <87pm4g7gxz.fsf@localhost> References: <871qhnr4ty.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> <875y6939jl.fsf@localhost> <87jzup1p4x.fsf@yahoo.com> <87wmyp1oor.fsf@localhost> <87bkg11ln1.fsf@yahoo.com> <87o7k11kn5.fsf@localhost> <87jzuozw57.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="4442"; 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 Tue Jul 25 06:29:34 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 1qO9fx-0000wj-Rn for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jul 2023 06:29:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qO9f3-0008DD-MY; Tue, 25 Jul 2023 00:28:37 -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 1qO9f2-0008D0-2V for emacs-devel@gnu.org; Tue, 25 Jul 2023 00:28:36 -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 1qO9ez-0004OL-KY for emacs-devel@gnu.org; Tue, 25 Jul 2023 00:28:35 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 40DF9240027 for ; Tue, 25 Jul 2023 06:28:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690259311; bh=may+SkvzM+ENN99pYq9jluaGiQOImlOX4zUBhx0Syrc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=d20oGePJNiO5m4e8xe5YiimR1QYwrD3LZB60x/9zdYeg0ozYp/Pcpm37IxlA7uaJS BtsmStfPUWq0Ov/rFyJMz6P5C4BjSiE1hCdFvGSIKsrWYaBEDrm/J2NEApE8s4VD8V hlZr8Vlgl41Ra//ieNchkc95sqnQiB+AooL+SiMK+AefRuBVEVp8atdwJAqhhBknsQ bU5hPs4pkMdPMUsR9SEKK5GN9ls8paj52PIqK6x1z4Y1knT2hO53UeJS8+Y5r5u1r1 Uc9ly3FfNj5kFrGRYvlN1uNxra6Wr51mb++L+BQWQlwEipskvHBWDKF7LnmQEtxS9K UtH8+Q5cDH+qw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R93tk3KdKz6tyf; Tue, 25 Jul 2023 06:28:30 +0200 (CEST) In-Reply-To: <87jzuozw57.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: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.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=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:308071 Archived-At: Po Lu writes: > Ihor Radchenko writes: > >> May you please elaborate? >> I routinely deal with buffers having hundreds of markers. >> How will adding a couple of markers from threads will make things worse? > > See bug#64391 for a performance regression in Gnus resulting from a > _single_ marker. That's not a single marker. Quite far from it. /* Record the accessible range of the buffer when narrow-to-region is called, that is, before applying the narrowing. That information is used only by internal--label-restriction. */ Fset (Qoutermost_restriction, list3 (Qoutermost_restriction, Fpoint_min_marker (), Fpoint_max_marker ())); will create a pair of __new__ markers every time it is called. And, AFAIU, did not clear them all the way until the next GC. So, the reproducer mentioned in the report was likely dealing with a growing number of markers. There is no doubt that processing markers takes time - Emacs goes through the whole marker list on every buffer change. But it is acceptable when the number of markers is moderate, not in the pathological cases with huge number of markers. Note, however, that it can (and probably should) be improved. As discussed in the past, we can utilize itree.c to store markers and remove the need in O(N_markers) processing when updating marker positions. >> Usually not. The worst case could be some match being skipped, which is >> often acceptable. I have seen plenty of examples because Org provides >> `org-element-map' API where we allow the user function to change buffer. > > But Org doesn't run in another thread, does it? Besides, text matching > is hardly the only tasks our users want to perform in a different > thread. My point was to show that per-thread point can be quite useful. I did not try to prove that all the possible tasks potentially done via threads need it. Text matching is one of the _common_ tasks when working with buffers, don't you agree? >> Point and restriction changing unpredictably is much bigger problem in >> practice, because it can be triggered even without editing the buffer. > > Code that believes this is a problem should devise and make use of > additional synchronization protocols independent from Emacs's internal > buffer synchronization. Please refer to my other message where I showed why synchronization is extremely difficult with the available tools even for something as simple as incremental regexp search. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at