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: a random backtrace while toying with gdb Date: Sun, 30 Jun 2024 15:16:55 +0300 Message-ID: <86bk3ihbgo.fsf@gnu.org> References: <87bk3jh8bt.fsf@localhost> <867ce7hvvz.fsf@gnu.org> <86tthbgdlr.fsf@gnu.org> <86r0cehkwr.fsf@gnu.org> <86jzi6hhjv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30567"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org, eller.helmut@gmail.com To: Gerd =?iso-8859-1?Q?M=F6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 30 14:17:53 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 1sNtVA-0007gx-Lu for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 14:17:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNtUn-0005ed-Qn; Sun, 30 Jun 2024 08:17:35 -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 1sNtUP-0005Yh-Ee for emacs-devel@gnu.org; Sun, 30 Jun 2024 08:17:06 -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 1sNtUO-0001PP-Og; Sun, 30 Jun 2024 08:17:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=lk9RkanCWsEo/X0zAxPkVvjIvGfp+OFP+oAZAUxUjgs=; b=UW03rL6ggGmcW++RQfq5 Qi3CNgTsmCHOaAZ1eAQpC1YQmD1bh+1zHjRw12c982aYgdXvjtfN11CsvSASFF2sJqPzzRaSTrMRf fuSGHrT4BZq40JhQV1IxcduNft6zXO7SbjkmRdQFIYv9i2+b7MXaeJvNGkubM1SOfPE3LFI7+Dqp+ Ei7iWs+HZYHqGWl0LdOp5UPIk0Ym6xSt+/vIy7XFsoZmCkNTiqdt4mnfuRL07yBmMERa0q9rfufJH dMvQ1syGL9GuWf2gjfI51M7y7VgrDeK4Hi/TlSIksWeb7bYlWHCRJWYc4dMzVAyZ/CZ+mejwGy7OA BWgSZ/4TfXO9nQ==; In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Sun, 30 Jun 2024 13:20:30 +0200) 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:320956 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org, > eller.helmut@gmail.com > Date: Sun, 30 Jun 2024 13:20:30 +0200 > > Eli Zaretskii writes: > > > What alternatives do we have? Emacs code deals with Lisp objects and > > memory managed by MPS all over the place. In many case, the > > programmer doesn't necessarily know whether some data is or isn't in > > memory managed by MPS. > > We know what we do in signal handlers, don't we? We'd not call the > existing GC for example, and we have to be awware that GC mark bits ay > be set. It's not that this is a problem all over the place in Emacs, > outside of signal handlers. Reality check: please re-read the code of our signal handlers to see what they really do. > > You are asking to do the impossible, IMO. Refraining from touching > > MPS-managed memory from signal handlers is simply not practical in > > Emacs. E.g., it would make the profiler useless, because the minimum > > you must do from the signal handler is to see which Lisp function is > > being run; if you defer this for later, you will see a completely > > skewed profile. > > The profiler is a special case that is true, but we could get away with > doing something special here: detecting, with igc_busy, that we > shouldn't do anything with Lisp atm, and instead do whatever goes. The profiler is not a special case in any way. The other signals I mentioned represent similar issues. And what about SIGUSR1/SIGUSR2? And SIGALRM, which is used for atimers (that are the basis for hourglass cursor)? Heck, in TTY mode C-g triggers SIGINT, and we process the key from the signal handler! > If you insist on making MPS usuable in signal handlers, please go ahead > of course. I can't, I have too much stuff on my plate. And implying that any disagreement must mean go code it by yourself is at least unfair. If you are unwilling to try what I suggest, I guess the future will tell who is right and who isn't. My fear is that going your way will mean we'd need to disable many useful Emacs features or make them much less useful.