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:43:20 +0300 Message-ID: <86cynyhfsn.fsf@gnu.org> References: <87bk3jh8bt.fsf@localhost> <87wmm6rcv1.fsf@gmail.com> <86le2mhhsj.fsf@gnu.org> <875xtqramd.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="808"; 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:44:09 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 1sNs2T-000AYc-DG for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 12:44:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNs1u-0005qc-Q9; Sun, 30 Jun 2024 06:43:34 -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 1sNs1t-0005qR-4q for emacs-devel@gnu.org; Sun, 30 Jun 2024 06:43:33 -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 1sNs1l-0001LZ-7p; Sun, 30 Jun 2024 06:43:32 -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=W/V9f06efy26tX1gBo1XaTJTSQTeB1/rC3fqmMQatRg=; b=F/tWGt3SfaM6 ntwWrDvcfoWB96CpEvPrgVMtLIxVXjGmTLGZmpMX4y80qr0DZj6KbVhs5FvZfGTitNt6OBPmUcM2Q /UYnnZiWLK+Adi+C3CecQ92MvLTpH+mjaaOXNTOFNGrrbq3rEQzwFeUTzx2ZvpYuzdMIgW+4Bcgny 1Ugm85UY0ejRv26lj45UDbiRZNjiUIenYHwfQsXktZTFfhAyvpMczXJgmR6eqF8mWZ0bqH413K3uy hoB/fJGdNc4o092ZEMVCMVzZvm+BKb0dCgqBOgUgEOq5kYrrQzWDkcowHtWDFROkT/wuilz00TsF/ tRmxU7yk+TFrWb7QNX/oYQ==; In-Reply-To: <875xtqramd.fsf@gmail.com> (message from Helmut Eller on Sun, 30 Jun 2024 12:24:58 +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:320941 Archived-At: > From: Helmut Eller > Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, yantar92@posteo.net, > emacs-devel@gnu.org > Date: Sun, 30 Jun 2024 12:24:58 +0200 > > On Sun, Jun 30 2024, Eli Zaretskii wrote: > > > 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? > > You don't do anything useful other than packing up the arguments that > the signal handler receives and put them in the queue. What arguments are those? SIGCHLD doesn't tell us the PID of the process (or any other data that could be used to identify the process), AFAICT. What if two or more sub-processes exited while we are in MPS-land? > > 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. > > The queue is not in MPS-managed memory; so we can access it. I'm not talking about the queue, I'm talking about accessing the data which needs to be put on the queue. The deferred job must be accompanied with enough meta-data to identify what happened, otherwise the deferred handler will not know how to do the job. > > 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. > > The MPS documentation says quite clearly that a scanner must not access > MPS-managed memory other than the block it receives as argument: What do you mean by "scanner"? I was talking about our signal handlers. If they qualify as "scanner", please explain why. Anyway, if a signal handler cannot do anything useful, the only alternative is to block select signals around code which could violate those restrictions.