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 13:00:12 +0300 Message-ID: <86le2mhhsj.fsf@gnu.org> References: <87bk3jh8bt.fsf@localhost> <87wmm6rcv1.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25328"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 30 12:01:19 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 1sNrN0-0006P0-9c for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 12:01:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNrMD-0001us-Kk; Sun, 30 Jun 2024 06:00:29 -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 1sNrMC-0001tS-Jm for emacs-devel@gnu.org; Sun, 30 Jun 2024 06:00:28 -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 1sNrMB-0003ip-L1; Sun, 30 Jun 2024 06:00:28 -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=iq0k0P9KIlEgohISIDj/swgrQjUjWcU8Hf0Br0b8LMM=; b=XhXfJNK5e+e4c6hHMlew uLtkj9hkt1YsMC0StMtlse4yPGe0fOoXxuip24wO2cuCrvgx/XwXZSpxTq7Mn9DWpQOGYyNLQDrod uu4tM5JGVJwHMJMt8B5L8z3Q4lnd5Qh6rUeFiGRYgicVL5TWznGhwnn7+uOGlaB0yCbn0OJASSCs/ cj7PKWgRMksDPEOdPfbyidGppissnfizuZxGvjqwLCzwCLHozWSRErNV+rh1ZTLC24ipRf8Vctj0u PT8XMvObInuhXSZ8hQo6dokhfRFmI7+omihkDWLZPf19FQz8QTMhlyXNd4Xy+IyKnVKQgDhNHcyT+ CRRgIDHrQ5k0hw==; In-Reply-To: <87wmm6rcv1.fsf@gmail.com> (message from Helmut Eller on Sun, 30 Jun 2024 11:36:34 +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:320930 Archived-At: > From: Helmut Eller > Cc: Pip Cet , Ihor Radchenko , > emacs-devel@gnu.org, Eli Zaretskii > Date: Sun, 30 Jun 2024 11:36:34 +0200 > > On Sat, Jun 29 2024, Gerd Möllmann wrote: > > > Someone has an idea what to do with that? And maybe how to reproduce? > > I can reproduce it with > > /src/emacs -Q -batch -eval '(dotimes (_ 100) > (start-process "foo" nil "sleep" "0.2") > (igc--collect))' > > I would move most of the work out of signal handlers. The signal > handler could put the work in a "async work queue" and then return. The > actual work is then processed by maybe_quit. But in this case we hit the barrier just by accessing the process object. How can you do anything useful in a SIGCHLD handler if you cannot even find out which process exited and how did it exit? Surely, something like that is needed in order to put any work on some queue? And I'm not even talking about the effects of deferring this job "for later" on the speed of working with sub-processes in Emacs. IMO, we must find a way of touching MPS-managed memory safely from a signal handler, otherwise writing signal handlers will become an impossible job.