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: Concurrency via isolated process/thread Date: Mon, 24 Jul 2023 15:44:24 +0300 Message-ID: <83edkxsclz.fsf@gnu.org> References: <871qhnr4ty.fsf@localhost> <83y1jtgmbw.fsf@gnu.org> <87zg49xfke.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7145"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 24 14:44:29 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 1qNuvN-0001gG-B6 for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Jul 2023 14:44:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNuuf-0005Ni-Ta; Mon, 24 Jul 2023 08:43:45 -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 1qNuuc-0005Ml-Tp for emacs-devel@gnu.org; Mon, 24 Jul 2023 08:43:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNuuc-0003s6-Fm; Mon, 24 Jul 2023 08:43:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lFMqsotON0qY07st6c9Hw/Yc5ORTAHJQueqfoM4KcgI=; b=jry/B6Jgkxpk GJ9K7do4xBTc6MZJTl1/FClSIuXgjDKemFuqW6EJEF38tuqcM73Gi5GkJS7y36jjzVKMF5LNPySiY W9UWbwcSZP8bSOvn1qZPVilbM629Sx2OhkOlSt98kjqjeSdofUdFneL1nxU4B66WV2ltSz0ZtwcUu tPm9eoPTDvI8yw/cBUoFpjD3t3mgaat5m1eixkZwYZhYF60eNztjWLBZnJDjoBU1Kz+8nCM7HMS9J ZY7nGWo2ZOudGDuR57F3OINrHC+f4dPfPhCQ3QgHI6BMPqeltm6G5/lt+iMczJmnTccwSztpzWRRi IN1VvSYcFMQvLu3trVWW8w==; Original-Received: from [87.69.77.57] (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 1qNuub-0004fg-Vu; Mon, 24 Jul 2023 08:43:42 -0400 In-Reply-To: <878rb53dkj.fsf@localhost> (message from Ihor Radchenko on Mon, 24 Jul 2023 08:42:52 +0000) 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:308053 Archived-At: > From: Ihor Radchenko > Cc: luangruo@yahoo.com, emacs-devel@gnu.org > Date: Mon, 24 Jul 2023 08:42:52 +0000 > > Ihor Radchenko writes: > > > 3. Current buffer, point position, and narrowing. > > > > By current design, Emacs always have a single global current buffer, > > current point position, and narrowing state in that buffer. > > Even when we switch cooperative threads, a thread must update its > > thread->current_buffer to previous_thread->current_buffer; and update > > point and narrowing by calling set_buffer_internal_2. > > > > Current design is incompatible with async threads - they must be able > > to have different buffers, points, and narrowing states current > > within each thread. > > > > That's why I suggested to convert PT, BEGV, and ZV into > > thread-locals. > > Would it be acceptable to convert buffer PT, BEGV, and ZV into > thread-local for current cooperative threads? General note: it is very hard to have a serious discussion of this kind of subject when the goals are not clearly announced, and there are gaps of week or two between messages. Discussing several separate aspects of this makes this even harder to follow and respond in a useful manner. > I am thinking about: > > 1. Removing pt, pt_byte, begv, begv_byte, zv, zv_byte, pt_marker_, > begv_marker_, and zv_marker_ from buffer objects. > 2. Adding pt/begv/zv to thread object. > 3. Adding an alist linking buffers and past > pt/begv/zv positions visited by a given thread. > > This way, when a thread yields and later continues executing, its point > and restriction will not be changed. Why is the last sentence a worthy goal? what do you think will be the advantage of that?