From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Fri, 23 Aug 2024 18:57:12 +0000 Message-ID: <878qwn6pa2.fsf@protonmail.com> References: <877cc88j4p.fsf@protonmail.com> <86seuvre6x.fsf@gnu.org> <8734mv8yb6.fsf@protonmail.com> <8634mvqte0.fsf@gnu.org> <87o75j73ry.fsf@protonmail.com> <86v7zrpawy.fsf@gnu.org> <87ed6f6xvc.fsf@protonmail.com> <86le0np62c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23891"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 23 21:12:58 2024 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 1shZiT-00063N-Kd for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Aug 2024 21:12:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shZi0-0003KZ-QX; Fri, 23 Aug 2024 15:12:28 -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 1shZTM-0002H9-8a for emacs-devel@gnu.org; Fri, 23 Aug 2024 14:57:20 -0400 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1shZTJ-0003lR-O6 for emacs-devel@gnu.org; Fri, 23 Aug 2024 14:57:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724439435; x=1724698635; bh=ph08XJ/OiDKgzFkakbcK38oGtFMussE0gstn14qYUZk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=foV7GJdEl9ZJS5Yl+MTSNgej9lwVYFEpemGmdwWKsVsl4oFuCgjAiHPciaMN8ZkYw djksQ7BxsltuXxtys9e6j7dLDaPoJtJyV+XLYrO3dcKryPEb8WaKottLQQo9IZQ0IO iIViulemrMr4Mu/SSnsnV2Fo0WCS5hoHqNez+lqnh0qhgpH88F+hqLhyYVLfZZwRVd K9QM1W+7vbm9cfXRvbQ1hWEeRDDP+1lluw9mV2YOPHcLQGLKrKLj+zJasEU0CZCHrk jkrJA8eQxjpNy/XMDA1bn/U/aKeYEEzMSE3kZhdH7mdoZBgAyrSaE4po4UVWGYMhWQ uNvsvLifim+fA== In-Reply-To: <86le0np62c.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 03e84ac13d62cdf714ab65b869a8eb6930f406a6 Received-SPF: pass client-ip=185.70.43.16; envelope-from=pipcet@protonmail.com; helo=mail-4316.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 23 Aug 2024 15:12:26 -0400 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:323099 Archived-At: "Eli Zaretskii" writes: >> If your point is that it might be a long time until MPS is stable enough >> for very unusual configurations, that is certainly true, and affects >> when it's a good idea to enable it for general use. > > Not "for very unusual configurations", for all configurations, > including the most popular ones. Which ones do you mean? > We are touching the most delicate > parts of Emacs, and will probably touch a lot of them (unless we find > some simpler, more reliable way of preventing these problems). Simpler, maybe, but reliability, I will keep insisting, improves if we think about why it's safe to hand off a pointer to GCable memory to an externable library. >> >> This particular call is safe. 'match_data' lives on the stack, MPS >> >> treats the stack conservatively as pinning every object to which it >> >> might possibly refer, thus 'match_data->pattern' cannot be moved. >> > >> > IOW, we are lucky. Because match_data could well be a global variable >> > allocated off the heap, or something else. >> >> Which would be a bug both with and without MPS, as nothing protects >> match_data.list from GC if it doesn't live on the stack. > > ??? We have gobs of those, and know how to protect them. The easiest > way is staticpro, and there are others. My point is you'd have to protect it, albeit slightly differently, with or without MPS. Not that much changes with MPS, and to say it works because "we are lucky" is inaccurate. >> >> The change I proposed is redundant: it tells MPS not to move the >> >> pointer, and it uses a pointer-to-a-pointer to catch potential moves. >> >> Only one part of that is needed, but in both cases, we need to rememb= er >> >> to un-pin/free something. >> > >> > If the change is redundant, why did you propose it? >> >> Better to solve a problem twice than not to solve it at all? > > Not in my book, no. Since Emacs is stable, we should not add any code > that is not strictly necessary, otherwise we risk unnecessary > problems. The master branch may be, but there's nothing wrong with keeping our options open on scratch/igc rather than leaving in a few "redundant" safety checks. I agree, though, that a comment is in order here. Pip