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: Mon, 23 Dec 2024 18:44:42 +0100 Message-ID: References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> <86seqe4j4f.fsf@gnu.org> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.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="34852"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 23 18:45:23 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 1tPmUd-0008ti-ED for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Dec 2024 18:45:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPmU6-0003ki-Az; Mon, 23 Dec 2024 12:44:50 -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 1tPmU4-0003eG-Dz for emacs-devel@gnu.org; Mon, 23 Dec 2024 12:44:48 -0500 Original-Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tPmU2-00052i-L2; Mon, 23 Dec 2024 12:44:48 -0500 Original-Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-aaecf50578eso246344866b.2; Mon, 23 Dec 2024 09:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734975883; x=1735580683; 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=QL5g/QPsXyCxa+dHDm8rIXgYDM+emqM1CKjiVAgT3Lw=; b=ScllubZtPexIWeoyVNhB4UotEcYohZdyvdhO2c3z1IHaFcsi01QPBGhROa/OZDBG5e ZalZGjkYq22Lv83npEiKJD51F4oy8CZRYp/FeJydtoZvcrOPUqwd3VDnbZm5+veAAsZE 2T0ixXre/DPhGoXjpu3AucQ88YxlmZpRi/CnGo8AjohlaYHyZ8l5FYiyKW9THcIc8krC 0ND0AcUoJAIKe55oJS9E53ecpmGkTFwwTg+1y2j74chD/vujCOvrKZwdnRxPLH///vtA 9LTcKpYYMxnp6Gf6xElCyRL+NMMQUkGvE14DKkv3Ghlkk7PmFn7M6boYWeU1Zgf8ymjd xlyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734975883; x=1735580683; 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=QL5g/QPsXyCxa+dHDm8rIXgYDM+emqM1CKjiVAgT3Lw=; b=SnRHeopDSbg+rAZCRoeXtJisPaFrwSWDX/tuuiDAZAvoaRI+20OcSF1Epi5bXcapSU hToR6si6X0541pGYUOk0QRnwVRUK50anW/XQW4WYnmXaUn0R4Ip6E/p36R2d2Dk6S5IH maSUW5DS2zHmbIRhgjBQYPDEdpem5ZZ8t09l6maAXSNElie3Z7ifOmfuv6sWU7JUgZs1 1q9ynmadRvIv7B6rSHMRLOjB9D8NBp79stqAZ9nWxdyDJQv0kxm4o5rycbi9IJTnnm2v vfoEliC/AfZFj81akR9hdjiX9/Dm3jvSmjZpeZFG6n7rsU+Czjbx80Dby6lS8YcWZ99D caLA== X-Forwarded-Encrypted: i=1; AJvYcCVztjvTTyfr8+7RwdPcL43nMSRpUaZxfPTQTrKKxHDvkOeq099w/0in/WpYAW97QQDti3CCUFH5uD+HklA=@gnu.org, AJvYcCXZACPq3yRAIF2+x2YBUYhbuyFNVyH5uNtKVfLkVV1sus6wDPS7Icbh7qICIKA/yB5VeN8RUg79vA==@gnu.org X-Gm-Message-State: AOJu0Yx54mqpMNe8tohyVQ4Gc7l/WS3Idu6AriDQuV5Yh4dJ25d7OxB+ Z/m+r9W2Jl4AWQNdgnveY0rGwzfv6n7e75ZYoAmXjdDHCqWbOikAccQW/A== X-Gm-Gg: ASbGncsN9N2vKA4luDyDFnKbuY796DEOtEHqmOVPqNRP7v8h+TZitc8PXqZe18yMvj8 ZAth2tPk3o4zHNJ0C1Bm8BXnNAr7a2ieoyjXvkVUlX/05PSj+AF8a8M85GBYIvm2z4DddJif5Vf KJ3AnHjJGUJM+ijzcC7gRX5tenBtWoZsqLaKU92qZcNz3Y/iV7QKWoGZzGHZtI8gi9fbV3V5I9G j4TCJnluYrSU6abYvD8TsZvPUgA2QmHZiprR3bftTp3mSV87AIX7ejKvifFsKgctxjSNha1p09B 1pLBXgP9CH/o1HJ4o/2adfPlXKRwZUBchxCwqXCPJ/WP65rxjudZog7wMmrXYMuNhQ== X-Google-Smtp-Source: AGHT+IEbs1ipcY8oXxVphE1mLu4b+0FeExhFBh8JD6kqA5Jib7VN34zNxuxEABCfxb+lPpY/nFHOmg== X-Received: by 2002:a17:907:2d28:b0:aab:ee41:eab8 with SMTP id a640c23a62f3a-aac2ad82b21mr1183526866b.13.1734975883274; Mon, 23 Dec 2024 09:44:43 -0800 (PST) Original-Received: from pro2 (p200300e0b728c00045f88d4d4db0c1e7.dip0.t-ipconnect.de. [2003:e0:b728:c000:45f8:8d4d:4db0:c1e7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0efe4667sm547181966b.125.2024.12.23.09.44.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Dec 2024 09:44:42 -0800 (PST) In-Reply-To: <87pllicrpi.fsf@protonmail.com> (Pip Cet's message of "Mon, 23 Dec 2024 16:03:53 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62f.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:326924 Archived-At: Pip Cet writes: > Gerd M=C3=B6llmann writes: > >> Pip Cet writes: >> >>> I'll spare you most of the details for now, but having read the mps >>> header, MPS allocation is not safe to use from separate threads without >>> locking the AP (or having per-thread APs), which we might end up doing >>> on Windows, IIRC. >> >> Now I'm confused. We're using thread allocation points. See >> create_thread_aps, thread_ap, and so on. > > I was confused. This is only a problem if we allocate memory from a > signal handler, which is effectively sharing the per-thread structure. > > (I'm still confused. My patch worked on the first attempt, which my code > never does. I suspect that while I made a mistake, it caused a subtle > bug rather than an obvious one.) > > And we don't want to allocate memory from signal handlers, right? We > could, now (see warnings below): Can't speak for others, but I wouldn't want it :-). I can't cite myself, but I'm pretty sure I said some time ago already that in a portable program one cannot do much in a signal handler in the first place. So I wouldn't be surprised if MPS didn't support being called from a signal handler. Not unreasonable for me. But whatever. Maybe Richard Brooksby answers, and can shed light on that or has ideas, if we don't overload him :-). And anyway, there is now something workable in the igc branch. Maybe we could wait a bit, and just proceed with something else meanwhile. [... Thanks for the patch ...] > Warnings: > > This is the "slow path" only, used for all allocations. Will cause a > great number of busy-looping threads.=20=20 Don't know why, but the busy looping threads makes me feel a bit uncomfortable :-), > Will be very slow. Creating additional emacs threads will result in a > proportional number of additional threads, which will be very, very > slow, so don't. Requires pthread.h and stdatomic.h, and still does > things not covered by those APIs (memcpying over an atomic_uintptr_t, > even if we know that its value won't change, is probably verboten, and > definitely should be). I *think* this code might work if we allocate > from signal handlers, and I think this code might work on systems that > don't have lock-free atomics (once the #error is removed), but it > definitely won't do both at the same time. > > Pip BTW, do you know which signal handlers use Lisp, i.e. allocate Lisp objects or access some? All? Or, would it be realistic to rewrite signal handlers to not do that? One thing I've seen done elsewhere is to publish a message to a message board so that it can be handled outside of the signal handler. Something like that, you know what I mean.