From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Wed, 25 Dec 2024 12:58:09 +0100 Message-ID: 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> <87r05wgezn.fsf@gmail.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="11433"; 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: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 12:58:37 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 1tQQ28-0002pz-Op for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 12:58:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQQ1o-0008B0-Q3; Wed, 25 Dec 2024 06:58:16 -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 1tQQ1n-00089j-4W for emacs-devel@gnu.org; Wed, 25 Dec 2024 06:58:15 -0500 Original-Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQQ1l-0003Rb-KV; Wed, 25 Dec 2024 06:58:14 -0500 Original-Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a9e44654ae3so934164766b.1; Wed, 25 Dec 2024 03:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735127891; x=1735732691; 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=cvCX3EaZ//X9vusI3+Cx6HOKnGGf1INDoTMTBj+cVIM=; b=A7zi4Nhv8yUxp/Vs1LWUu9eJEnlVBHa7Az2L+BvosJnRbxvoex4fVEpHL8naYc61UO FxSDqTvLlI6C/ACTnWSnt9qFCjuF39sx26YDK61pYPsB8SO/hazyboXmuy8Y43VGFGgz kqjiZzpLl4imkuYyGNR6crad+6sBUmcQRao/b/VaF3oU48KgwDn41N1OEHcHI7KRHGJJ KypUeFSPbp4x9lw0uDtqGXwRQFHqpDdPsuU3kN/R9RobK4Z/NYstH8mVFkPpqCzFJtln Q0j8RhB5gfGnPTnjtlvNR+tZZc5PhXSYkhTUi8CfhSt9joX4AcAjicSBINF28SWUApMt zzww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735127891; x=1735732691; 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=cvCX3EaZ//X9vusI3+Cx6HOKnGGf1INDoTMTBj+cVIM=; b=idsKtne2ZdyiGtmvgxRcf92jerLMmN6ykdyWI5RN6iQ0qEbyYtzv172aQY/bQZTFfr bLgw2DjdSt9EJIujukeOAIWE1X7MqhSpKN4lspcUzgnZ0D9gDInc5DQ8PbS+3bKQDRmh 99LU2wUF3s0UBVlQ5Ia8F5Te8DwDwfa5xfH1d2hCt+hPwZhGXpNNsxp8XPOY8pisBq1E pzBXyvZd2YA6/XNJLKKTbTr+NYmn58Bnajk3Ic7FkFWBfKUu+JgMg7WjWenlDtzrgJky Lp3bfmZYOU2rJqOKSKjqw6BxYA87wheTwwKEnuadhqsBKRulUmdbE/rMrbqdIq6cV8tt 2Q7Q== X-Forwarded-Encrypted: i=1; AJvYcCUfAOo1YW/Kfb5Zn20TiGCsJSkCiVUoh94iUHK/90pOh+RcWWg7oYQDTXNo3yFTv2uNPNd3vjx1JEEa33Q=@gnu.org, AJvYcCUxdzbnTTrOjFrD4dRzziKaDoGODYun0W5wrv0r3z/qAFE9vNwu51jD8rZtpsbX1j6Pj8s1ZFJn/w==@gnu.org, AJvYcCX7yfwOpuJCf1qLMSjIU3F7pFxvgvWjwFnsEEYeH2Tc4Orhp3OXIMS5T6UZ6UuCymnvcI0ApQ==@gnu.org X-Gm-Message-State: AOJu0Yz+/N/HkVrI8ucTOlzYy4nxoAHN0Gp6eN/WcEfdVtJY2PF60a5k MOpXuqSMlXECNli4RyL0qZjZEEyIs55dtLpWIU8bfVc2i5c4SkbXbZtKLXSn X-Gm-Gg: ASbGncsye1QOvJgtNQ2xPchN7rJfTq1bdB73/Qv5HO7IuNLSnq3B6FciR9E4ulSfHza sG+/h87rChjXItFeeO5R2rCEjWxWGtSDHnwOVgSMeYp0cTWQvhX+GTZCYrhg56Rf3LsAw+tjN+P UTH4SNR2ea22NeoP48imz0lb3M7pCRiumfWOXySnz45Km+651Lnt7um5/S+sequgNbaMR+r24gl E9PN+7NaLqiQlo+jmkjaAQAkkvtUVykYR86tS5coMhV8McMsfeQmTb8ZPwGja9VsLoGWBpj5y3B epcssT1a11Glnj0kZhH98lWbJuSA2GNCTOzWZbfVoP4BS7uYl0Ky+HOzUAuMqrNBHw== X-Google-Smtp-Source: AGHT+IEmg7IAoYCbCMPiECLhHFBw7AeBdWyeploplnmkVJGQg7kDUhIrK/tUr9dmdwhm7XhLInzbxQ== X-Received: by 2002:a17:907:7f0c:b0:aa6:7ec4:8bac with SMTP id a640c23a62f3a-aac2ad89af5mr2099091166b.17.1735127890711; Wed, 25 Dec 2024 03:58:10 -0800 (PST) Original-Received: from pro2 (p200300e0b73d6f00401d1c7c2fc22e2d.dip0.t-ipconnect.de. [2003:e0:b73d:6f00:401d:1c7c:2fc2:2e2d]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e5029f8sm786008266b.0.2024.12.25.03.58.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Dec 2024 03:58:10 -0800 (PST) In-Reply-To: <87r05wgezn.fsf@gmail.com> (Helmut Eller's message of "Wed, 25 Dec 2024 12:48:44 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::62e; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62e.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:327075 Archived-At: Helmut Eller writes: > 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 I think the latter, i.e. we ignore it. I think, but I can't prove anything, that the probability is good that we get away with it. For example, We're only using the backtrace_p binding stack entries, so the GIGPROF would have to happen when in some code putting them to be in danger, so to speak. That's not so likely, I think.