From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Wed, 25 Dec 2024 12:48:44 +0100 Message-ID: <87r05wgezn.fsf@gmail.com> References: <87o713wwsi.fsf@telefonica.net> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <87y104aih6.fsf@protonmail.com> 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="21594"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Pip Cet , Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 12:49:45 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 1tQPtY-0005S5-SU for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 12:49:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQPsi-0003p9-3w; Wed, 25 Dec 2024 06:48:52 -0500 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 1tQPsf-0003og-V6 for emacs-devel@gnu.org; Wed, 25 Dec 2024 06:48:49 -0500 Original-Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQPse-0002Jk-Jj; Wed, 25 Dec 2024 06:48:49 -0500 Original-Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-aa67ac42819so822412166b.0; Wed, 25 Dec 2024 03:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735127326; x=1735732126; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=7HUHEqA7umjq8GICqEYLGtci7EVvKQSgKkekjpm5r8c=; b=lyXrPHkMYEmPwViIioB5Wz/AUAyA/D1kIHnV8KdrM365WYQ+Bd9SOfzEwBfVNVdKWR 4U+0UiC8IBgIbva3pj1P58+Scb/49bbLgg1z16aU95sFyV1ESzACmk/wr3HLfHbPiIdE RSMFYrJaBYxA5e6m2CKBAIf1UXVG0OBmXGuA1aB/KOaCCB8ZA89nvnt536DzaEdmxig/ 8WXsEE/EGQUn+zBHo76gyHCYwIufFwZKMAPfcnTZ6W/XO/rMenjtHk5rYwjou3B1+T2G MgNDFAXkEK5YE/Mf7xQS1GisJlBWjDEnSx74KqkZ7iuExb9y+VVa4Csenz3O7PsmkgWz z8PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735127326; x=1735732126; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7HUHEqA7umjq8GICqEYLGtci7EVvKQSgKkekjpm5r8c=; b=W6doMrEgt9rnxIvBv5xGLZhAVnzn+s+UYBcFpBUdFOser1Wg92BHVWGZoFvCaKzrC8 fEISfdPBofvYbDzuw6na8YFICBSSf+VyHzfKo9q30Vx6f20caWSxdM7zJyXEt8KBQzEy y07EG5Sn8nq+DBmfj3Ec0fToj2AWUBb5NocUSwOqtbxweVhdrMLlrG31nxww0tTeF76U 9w9yzqYFE5LCNmu+Lxff1XB2OrIt8vt+f7FArLroUcw76HBhgVpx7oJZ2upMls8dWlID T1a49vvYOm/kIN2H/fLqgC2JVt0X3o7qePaZtD4erazommNLhRHqcXPRfZbPovQh97Bh Dxtw== X-Forwarded-Encrypted: i=1; AJvYcCV9ge0ahdNW+QTHfiiOEzQ6NUot+roOH0F0wK23/tTz2peNNZTkNkfSC1ggmij90HvJXXtFXtpqyT6w7ug=@gnu.org, AJvYcCXBSIZ5LaiYCkxF0tbylY4ChBFjeqdMrNFmTpWEAaW2pIwfFmTaDlrh5pY0xyXQudYJC7zUfQ==@gnu.org, AJvYcCXP4iCV9eIVh843VMuELlJ4Qjp0HzVQyd/vztmlpwz0UVGPJpabHVjQ0PY9PbPSYaLH4tLwyXKSoA==@gnu.org X-Gm-Message-State: AOJu0YwdMHuA6VWZyji4AqPwvaDQ71EiXXMweeqB+1VRC/X6wFOmLwZw 020Q++dv8a120R0ujIT8KIMt00tS2C6ET9KaGrS86j6EjPoCAZknlIVRW3Li X-Gm-Gg: ASbGncvpRrQc0ArH2OIQtPLC0IvAl4q1iNaP+PWf3efpkh1+tqCIpqrawCuzNHotTvR deGoqyVNwUgG3705Esle58cL3A1NIB99N9RQIhcI6F/2/ax4D3NhQhClzpnsrdlMiinxzXa8WjO uxFEcUnl20qtiZ27TvAdq/hys8JagLRvcSln4r7e1mNPEzirplEGyxSVgMMpxgHvP8smSbGfnKE LS/Vy9hXHA12rK9ozDLpTuKCObfaW/sSxfFOmlVU7u4a3EYM98+sCo= X-Google-Smtp-Source: AGHT+IHFh2idvpou7QEsY1QwlW4bJlfvW06QORlNwcPnpnheuYIldXT1Mf7lpLNz9Lai97YtsiI4Og== X-Received: by 2002:a17:906:c14d:b0:aa6:af4b:7c8e with SMTP id a640c23a62f3a-aac34650860mr1849184966b.46.1735127325837; Wed, 25 Dec 2024 03:48:45 -0800 (PST) Original-Received: from caladan ([31.177.115.143]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e82f2fasm787084666b.9.2024.12.25.03.48.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Dec 2024 03:48:45 -0800 (PST) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Wed, 25 Dec 2024 06:23:49 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::634; envelope-from=eller.helmut@gmail.com; helo=mail-ej1-x634.google.com 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:327069 Archived-At: On Wed, Dec 25 2024, Gerd M=C3=B6llmann wrote: > Pip Cet writes: > >> I don't think that's the problem. The problem is that signals can >> interrupt MPS, on all platforms. [...] > And I don't think that's right :-). It's completely right that in the > SIGPROF handler everything can be inconsistent. That's true both for MPS > and Emacs. For example, the bindings stack (specpdl) may be inconsistent > when SIGPROF arrives. Literally everything we do in the SIGPROF runs the > risk of encountering inconsistencies. The SIGPROF handler copies part of the potentially inconsistent state to the profiler log. That same potentially inconsistent profiler log is used later, outside the signal handler. Sounds like a problem to me. Is it not? Or is the probability for inconistencies being copied so low that we ignore it? Helmut