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: Helping with MPS Date: Tue, 20 Aug 2024 15:52:01 +0000 Message-ID: <877ccbb3a9.fsf@protonmail.com> References: 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="18486"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jonathon McKitrick To: "Jonathon McKitrick via \"Emacs development discussions.\"" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 20 20:17:55 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 1sgTQZ-0004bx-2y for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Aug 2024 20:17:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sgTPo-000104-VV; Tue, 20 Aug 2024 14:17:08 -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 1sgR9V-0003mR-LQ for emacs-devel@gnu.org; Tue, 20 Aug 2024 11:52:09 -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 1sgR9T-00069T-Ci for emacs-devel@gnu.org; Tue, 20 Aug 2024 11:52:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724169124; x=1724428324; bh=tkk/+8JCANV688ULn3rVroeZMCIPbgbI8e8U4n0Vpmo=; 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=At52n5k8wNnAWABOlwO1qKYYIbyyOHeqa8Ga0yUfcSZzGNqDkJlb22uvc9xSSx1zy ozu76W+XBJbZPY6+69DhNR74W9tuE+T6xlCBFAnQb5ZeO65KXAYAMNfYRU9cHprQvP SkMfhvYq+GvbIvfgX9UHai16LRKx1shdyfiCUoQvy43RoFikWmg54qFeH61hJuKuqJ 2znWTl02bFplWG01JQSmkal5uAmBwJQ3KNdX5ezvwujSYQOpD+R5wrIbGeqU5mVyXV rXJtYO/ykQaQfoDS7EFMZhGNMb6/2SLeNQjwhEKGbpwH/QzCyuL8a17Dhow5t2CWsz P83gJXZQ2+u5Q== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c8f8431bff80e1967bdc012a18f11fee13307c50 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_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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: Tue, 20 Aug 2024 14:17:07 -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:322975 Archived-At: "Jonathon McKitrick via \"Emacs development discussions.\"" writes: > I'm going to run MPS on my personal and work machines, Thank you, that's great to hear! May I ask which operating system and CPU architecture they use? > and I'll report back here if I have any issues. Please do! Any feedback is appreciated. > I'm also happy to help with coding and docs if needed. Well, it's time to fix the remaining stability issue: signal handlers and MPS. I've been running a workaround for weeks now, and I've attributed all the remaining crashes to other causes, so I think it's stable, but it's not particularly clean. The problem is signal handlers may interrupt MPS, and then we must not touch any Lisp data, so we must (usually) delay running the signal handler until we've left MPS code. The problem is MPS code may be entered transparently by another thread, and then we don't know that we're leaving MPS code... My current workaround is to have a flag for each signal, plus a global flag, and set them when the signal arrives at an inopportune time. We check them when we know we just left MPS code, and that part usually works, but sometimes we miss the exit, and then we have to wait until the next 'maybe_quit' to handle the signal, and that strikes me as potentially too long a delay. So, if you're using GNU/Linux machines, you might run into crashes we already know about. I can provide a temporary fix, but it doesn't feel quite good enough for scratch/igc yet. Any comments or advice would be welcome, of course. > First question: Since the build succeeded and emacs is running > smoothly, what's the easiest way to confirm that my executable > definitely has MPS running? Attach gdb and wait for a segfault. If you can continue and Emacs keeps running, you're running MPS. 'M-x igc-stats RET s' should also work, and show a snapshot of MPS allocations. Just leaning on 'c' for a while in that buffer (which triggers a collection) has produced crashes in the past... Thanks again Pip