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: MPS: Win64 testers? Date: Fri, 23 Aug 2024 22:28:05 +0300 Message-ID: <86frqvox8a.fsf@gnu.org> 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> <878qwn6pa2.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5626"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 23 21:29:03 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 1shZy2-0001Ff-Iv for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Aug 2024 21:29:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shZxG-0004r9-Ho; Fri, 23 Aug 2024 15:28:14 -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 1shZxE-0004qc-20 for emacs-devel@gnu.org; Fri, 23 Aug 2024 15:28:12 -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 1shZxA-0008Qk-J5; Fri, 23 Aug 2024 15:28:08 -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=KuGrEqArssz/4zq+sORwEgcan1t/k3lqIgo95RnYS9o=; b=LPLzk6Ggv0lT NKfgU7Q8q7GYDlfjFrP8qoFkCQZZa0QZ8IK3kuxrIlZbev0c3aoa8ZW+sxDm7YWkd9DdYsiI/O3G3 gjbREC0+Y98xvtkFUiItgTBpcXO17ksCxgdql7DLsozg0ov6W19t2xrVCQbuNjS+cHTnAvke2I4KU 4DUc1Lhm8T3eAQrV3owMedA+YzmnyZC3ZAEk36q2hjULuEeT53tp6UHCK9D/M3JfCYN9dFxJj4YUe SZ5OPYAplCoGRTgBAWAPRNgNP56ZJsv76aQcrcrD2GLYJlMTDML87xSiHJLhYiUj2+FGI4aQ9jzE4 mR8FP+LWXVD7x/rOs8dZWQ==; In-Reply-To: <878qwn6pa2.fsf@protonmail.com> (message from Pip Cet on Fri, 23 Aug 2024 18:57:12 +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:323100 Archived-At: > Date: Fri, 23 Aug 2024 18:57:12 +0000 > From: Pip Cet > Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net > > "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? All of them. I'm quite sure we have a lot of corners the few people who are using the branch have not entered yet, especially as some bugs don't happen until GC hits at just the right (or wrong) moment. Like this GnuTLS crash, for example. > > 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. You can insist all you want, but you will never convince me. I have too much gray hair from opinions based on the assumption that we completely understand what we are doing by such changes and what they cause in Emacs. Just stick long enough here and you will see another example of this fallacy almost every day. So no, IME reliability definitely does NOT improve by futzing with this kind of stuff. Which means we should not do it unless we must. > > >> >> 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. "Not that much changes" is IMO an understatement of the decade. Compare the simplicity of staticpro with the complicated dance you suggested for this GnuTLS issue (which is not different from many similar changes installed on the branch each time we detect some similarly "unsafe" use of data structures). One can use staticpro without even fully understanding how it works and why. We have nothing comparable on the MPS branch, and thus no established procedure for solving such problems or rules for auditing code for similar issues. > >> 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. If we want this branch to ever land on master, we had better handled it with the same care as we do on master. Because when we decide to land it, no one will have time or motivation to go through all this stuff and "fix" it. We want Emacs to be as stable the day after this lands as the day it was before that. That's how it was for all the other major features that got merged from feature branches. Any significant drop in stability as result of the merge will be a net loss.