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: Thu, 26 Dec 2024 09:02:11 +0100 Message-ID: <877c7mzxbw.fsf@gmail.com> References: <87o713wwsi.fsf@telefonica.net> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> <86a5cj2a0e.fsf@gnu.org> <867c7n28sf.fsf@gnu.org> <877c7n962e.fsf@gmail.com> <8634ib24gp.fsf@gnu.org> <875xn75w7u.fsf@gmail.com> <86ttaryn1x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22524"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 26 09:02:46 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 1tQipS-0005lo-7L for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Dec 2024 09:02:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQip3-0003k6-DN; Thu, 26 Dec 2024 03:02:21 -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 1tQip1-0003jg-00 for emacs-devel@gnu.org; Thu, 26 Dec 2024 03:02:19 -0500 Original-Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQiox-0006kB-Ry; Thu, 26 Dec 2024 03:02:17 -0500 Original-Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-5d3bdccba49so10907901a12.1; Thu, 26 Dec 2024 00:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735200133; x=1735804933; darn=gnu.org; h=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=XYola4ubobF8rp6ug23wwiuf+nV5zeD6eVJ+sY9DYTs=; b=Uz1wos3/fxd8xA7kc5RBoj1OowR4hNBrjx8bOTqicEiY9k7DshLOXTDQIDNdyLOYo1 /HJCJluq9Njdx4QKg9p8G6M95O62rDgoVfnZ7XuofJJsEK7V9WSPOiiE0c9iVNik0G3A +BzyTYobSes3z+wt74mmdegWuIxTfYHRLAt11gIwqL0iMyR5rxzCwACnm1q+NN3qnr52 lu+/WVJ/NqJq57jYS6gETqUMzN0jmuCW8LG/6qaAiucoReJ/FbQgE+UcyG7G6d80lYtg 8wd9WjR+TUcC6sTNuxI/rhXKlsXFyDiWqWw8tu0It6Gqtp3XXZVgioQJZCogjlRrfZEe fhoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735200133; x=1735804933; h=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=XYola4ubobF8rp6ug23wwiuf+nV5zeD6eVJ+sY9DYTs=; b=NzkS8jq4m8k7G724psm6OyAeJbpamG5jWO1PIwrgNGprRhqAuYW4dX2XU/kpBxHFLZ nWBwRAvYUKtWSTmYQqtWoNhwfdIr7fNv0xEQA0PKCLfyvfWgpMVcVou27xOy2jMkPOhM KtbsIpQyV48G9VRVu9iy3H3a+VqYpGG3WAr790ceBjEMcuFSiqiuzice06c3PKzcdAFF UWJsmX+cVBZkuv/Ic9P17bFlbVmIm/3cFRR9oeyQHyxo5mQ/rpTLv/2/6ycAL68efZKR vuX4kCvvl9SXdSYfk2aRpSF9yug8WvEbWN2G7tziEf8mnLmFKOBb//zCuY2DDD3fe7rt pxCA== X-Forwarded-Encrypted: i=1; AJvYcCUwgjxJV330Fr4EIorpi74+zbRnmbn5HwX52UGKWvcKJurVcAnAkasbPwEwj88PrK9iOo8uYBUFLw==@gnu.org, AJvYcCVywe/zvkv4vf31dBGYkFqixwhuTEdkn4Et5Zck67LdtZPVwyTvmOZ2dndNG7Eq5LcTcrWAYtDJwfg+0ew=@gnu.org X-Gm-Message-State: AOJu0YwRMyS+F2FAcm6CsZxr33+0i+qOvBrcIJ4eHpbuIVVk6DSp2ttt 9KM/JW11NXEmkwSRXg1faXzEwDCW1jtajZzRhtTDDyc3EYUVxYLJfjL5GS8F X-Gm-Gg: ASbGnctyq1xTfZ8U29eq1a7pYpit2APmOpu9VIzS+SQSTKV4oLd/idkaR5ds/BXVoGa wYmm5dzp30/dYHfZlxSvtq5ChCb2rJRO3XhmVq0dNj2378d0bEDP2hMUr2Wh87jxCDA24KzmMqe mw8AojtJWSACHIATPv4B25mGB1XVFyroBrrigPllZMbWZnrj5HGWd56unvLTAQoQ53SwkhwW+PA O1njq9Q07ovX4ceBcVAsVwwSV/3LLRKusVYy17AbsEPAbcOP6eOiYg= X-Google-Smtp-Source: AGHT+IF/bozD1d+Fi24Pexpuko+VRXdVkmEu+DCMpCW1TaAuxx/Gf0hFjD6DvAT723AWXcwt4jy0wA== X-Received: by 2002:a05:6402:3486:b0:5d0:e73c:b7f6 with SMTP id 4fb4d7f45d1cf-5d81de2dd01mr17206784a12.31.1735200133125; Thu, 26 Dec 2024 00:02:13 -0800 (PST) Original-Received: from caladan ([31.177.115.143]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d80676f074sm9008291a12.25.2024.12.26.00.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Dec 2024 00:02:12 -0800 (PST) In-Reply-To: <86ttaryn1x.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 26 Dec 2024 08:29:30 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::534; envelope-from=eller.helmut@gmail.com; helo=mail-ed1-x534.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:327139 Archived-At: On Thu, Dec 26 2024, Eli Zaretskii wrote: >> > Which means we should try talking to the MPS folks so that they >> > provide us with the means of blocking some signals while the lock is >> > held. Like some callback MPS would call when it takes the lock and >> > another one when it releases the lock. >> >> Your position is that blocking SIGPROF while MPS holds the lock is >> the correct thing to do, right? > > Yes, I think so. (If you disagree, please tell why, and let's discuss > that.) It is certainly a relatively simple thing to do. I quite like Pip's proposal of re-installing the SIGSEGV handler with an additional sa_mask argument to block other signals. That would be nice because a) we can do that without changing MPS and b) it's likely more efficient than callbacks. It would still be nice to simplify some signal handlers, like handle_interrupt_signal, but with other signals blocked for SIGSEGV, it would all be quite independent of MPS. > It is also possible for MPS to somehow manage an attempt to take the > lock which is already held in a smarter way, by stopping the code > which does that until MPS releases the lock. For example, MPS could > define a protocol for such situations not unlike the GIL protocol we > use for Lisp threads. But that's much more complex, and I don't > necessarily expect the MPS folks to go to such lengths. I think that mps_arena_busy, which tests whether MPS holds the lock, is quite adequate for the SIGPROF handler. It lets us detect the situation and increment some counter. An advantage of blocking SIGPROF would be that no #ifdefs HAVE_MPS would be needed. Helmut