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: igc, macOS avoiding signals Date: Mon, 30 Dec 2024 11:05:44 +0100 Message-ID: References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <86ed1rswup.fsf@gnu.org> <87h66loc17.fsf@gmail.com> <878qrxoayj.fsf@gmail.com> <8734i5o6wc.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5906"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , spd@toadstyle.org, pipcet@protonmail.com, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 11:06:44 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 1tSCfc-0001Sk-9U for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 11:06:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSCey-0005uv-8a; Mon, 30 Dec 2024 05:06:04 -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 1tSCem-0005uV-Ef for emacs-devel@gnu.org; Mon, 30 Dec 2024 05:05:54 -0500 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSCek-0004uJ-41; Mon, 30 Dec 2024 05:05:52 -0500 Original-Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5d3e6f6cf69so15044340a12.1; Mon, 30 Dec 2024 02:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735553147; x=1736157947; 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=GOoWhoGWLK3gFukUQzcKiu2St9z79ZUPhRVwj+F9F+4=; b=gUuL1+taQdMtZE+zP14NKZYcL5UEqggGvNUp8BAYUcs20o/iqyknGV0E1JM7q/SqAX gz/7/kg0pnY41BmSqNWp3Pbk/S6RGTlDs+RljCmUs3eJ+V9wohHmh3WfDPjMuSiX6V8u 7FMKhlzyo4VgeG+3mh8lq1F8mHLeidKwniQrqBE2EIJMbOxE1iu3gv1Ytl/cvdC+5wmQ J/9YI5xYJ4bSleiLVHmU/FtIOii/r/AG8FP85RqL1203ewFE5hP1JBCxeMptYD8GYdBy l3qorFCwBAns31fdMe+JA04KEgxvGweOZ/V7oL8c8PBRYZ3OcbARnRAhqnNWorEuhu2P 1AIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735553147; x=1736157947; 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=GOoWhoGWLK3gFukUQzcKiu2St9z79ZUPhRVwj+F9F+4=; b=QOpDiYp1R7pHK9TOG8rKZEsB6fdCN8Jk22md03xIIA9ShlwvJ5qGtGls7GJWVzi8Nm SlelLcyRXOiiVViGogCiB5XSFelm+/g9r9mlwwgTBObJH8nBa4UH+wPyKuqOxGQgmGYU P5Naf47HVQ12N/pPMUGAVW6PxwxoXeJXoId1IhBrrv3Pcva5NpBp7ov+aOm5/CoiiBRU DSXuvgDz9ov29qrqOAIr7gWLMGx/m11CjQeTUAMo5evvInBBOlMtI8mgml7tuQJEe9qE tm26TPErIPuUtPYwM5jTUp3blOXwe+0GHIs4V1BLhAQsErLFrSm3o5rL04RMSXyzMNwY E/Zg== X-Forwarded-Encrypted: i=1; AJvYcCUUC1UVoRA8q5a88PiHfLgOILxYjmi+Ij/1hehCys2RhtJloHYYR8cKbm0fe0s3hAmILZHB1K2R3Rz5/A==@gnu.org X-Gm-Message-State: AOJu0YzbPonq7q7ur2CD5Tv7wtDVQz075ky6ywGEgeKyeCe+Fkv5GOZE KzQdrKDB39QGdRCdbg6XEUwqeDG/udZ/HOJ2/8gAQ/FvpIZSXECUAnzUDg== X-Gm-Gg: ASbGncu1DiUoJhOqQjOXPvh2uAcQnaY+DvLSAVe59LVQnL6L/bQr51RCFaOlM1nNAtn 8JuoiFp2ESnV5gmA2CWJL2bKP2SCft4P9aCWQsVCsId57rqHGrKS/D5z+NWNv4bqdsVJEuy4b4j xcDCCq/wBWIHtW6c0HpTXSzRKVinTMlZBlM3LxKg+rUOP6YEQSY7e2wrZv2P4GluBUlUmY9TRwR lL5CAgal9+xTR3jNJDJtkELqkdjt8VRF1dQF+CITILV3lkOrib8CDcng/TL0RqP3qavixRxRbTq GywDYqFvhTayX5aLASo0XTotCAsNekcqps/Scd+DMSMU4U/NP1tOS5jzBmp2Qu0I X-Google-Smtp-Source: AGHT+IHxSfp/P/aH3tGBmVPSq72zd+8zmrqbT2JOZlAT2FwP8fDSnidn0Otoe7cGeFgNWOsIS9DFHQ== X-Received: by 2002:a05:6402:4402:b0:5d1:2377:5ae2 with SMTP id 4fb4d7f45d1cf-5d81dd8474fmr31244866a12.7.1735553146821; Mon, 30 Dec 2024 02:05:46 -0800 (PST) Original-Received: from pro2 (p200300e0b7156f000dceccb84ca1ba38.dip0.t-ipconnect.de. [2003:e0:b715:6f00:dce:ccb8:4ca1:ba38]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d80701c9d7sm14480333a12.87.2024.12.30.02.05.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 02:05:45 -0800 (PST) In-Reply-To: <8734i5o6wc.fsf@gmail.com> (Helmut Eller's message of "Mon, 30 Dec 2024 10:29:55 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::533; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x533.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:327399 Archived-At: Helmut Eller writes: >> In the signal handler, hitting barriers is handled by the MPS port >> thread. Consistency of Emacs's state is a problem the signal handler has >> to deal with, > > Agreed. > >> consistency of MPS' GC data is a problem that hopefully >> MPS handles, and it seems to work. > > My interpretation of this design document[*], is that MPS's arena lock > protects most of MPS entry points. There are a few (e.g. mps_reserve > and mp_ld_add) that don't claim the arena lock and for those it's the > burden of the client to call them in a thread safe way. For us this > probably means: don't call them in a signal handler. > > The main entry point that we want to call in the signal handler is the > SEGFAULT handler (not sure how this works on MacOS). The fault handler > claims the non-recursive arena lock. So, in the signal handler we > should not hold the lock while hitting a barrier. Okay, that I think I understand then. The "only" difference between macOS and Linux is that on macOS no SEGV handler is involved. Hitting the barrier on macOS means that the EXC_BAD_ACCESS port thread, which was waiting for Mach message, receives a message from the OS and starts working. >> I think I understand that, except when the Emacs thread is interrupted >> while in MPS code, which happens for allocation points running out of >> memory and mps_arena_step (idle time). > > Hmm, is that sentence incomplete? I don't quite understand it. What I meant is that I imagine a signal interrupts the Emacs thread at a point where we are "in MPS". AreaEnter/Leave I think I understand, it's some pthread_mutex_t, I think, from other mails. A problematic "in MPS" could then be "while the Emacs thread owns the mutex". The places where I imagine that mutex could be owned are mps_arena_step (I call it Emacs is idle) and mps_commit (in alloc_impl, when the allocation point used runs out of memory). Maybe other places, but mainly these two. And the question on macOS for me would be if the port thread tries to qcquire the same mutex, or how the heck that works. Or IOW, if there is a problem, why I've never seen it happening in all that time I'm using igc. I find that difficult to understand. But it may be just a statistical phenomenon. Maybe filling up an APs memory is so fast so that the probability of a signal hitting while owning the mutex is close to zero, or something. > >> Do you agree so far? If yes, I'd bite the bullet and look at the MPS >> code for macOS how that is done, if it's done. > > Yes, mostly. > > Helmut Thanks for your help! I'll post something when I think I have something.