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: MPS make-thread Date: Sun, 23 Jun 2024 08:45:44 +0200 Message-ID: References: <87v823xvq1.fsf@localhost> <87frt63dvt.fsf@gmail.com> <86o77ulgk8.fsf@gnu.org> <87zfre1p3r.fsf@gmail.com> <87zfreo5u6.fsf@localhost> <87plsa1n8k.fsf@gmail.com> <87wmmio3vq.fsf@localhost> <87jzii1hbs.fsf_-_@gmail.com> <8734p61evv.fsf@gmail.com> <87cyoa3w5d.fsf@localhost> <87le2whkt2.fsf@localhost> <86sex4g53k.fsf@gnu.org> <864j9kfbm0.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="12044"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: yantar92@posteo.net, eller.helmut@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 23 08:46:52 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 1sLH00-0002ym-7c for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Jun 2024 08:46:52 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sLGz5-0002gF-2R; Sun, 23 Jun 2024 02:45:55 -0400 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 1sLGz0-0002bx-7L for emacs-devel@gnu.org; Sun, 23 Jun 2024 02:45:50 -0400 Original-Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sLGyy-0002oB-EC; Sun, 23 Jun 2024 02:45:49 -0400 Original-Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-52cdc4d221eso1549792e87.3; Sat, 22 Jun 2024 23:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719125146; x=1719729946; 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=gRou8atfUGeBQZn0IM1Di7dhr7ossIRLfZV52i9gAYE=; b=TkAJp8a6HMdIFGykeknVS8tExkbw/Uk8emw8bG3T4SGwY6wwinxUzPMvGujv3XW1KJ Se7F8PF3ORbUlgJbkzB0j5E6XRt6+BdAbKAj8LrSAxtoELjCCR7KUGDpLLGdGexP2r/D Lq2m72nCq6tQm425JILYGmMZJL31x8n706b6ir75RGA6qA/BPAxPp2Gbitp0QkbVlFVy mHp6SQADi2CDkfNcdho+b925zvB44YQsIfMUaTCwAsq5jdhUh3/KmhgcSzVkODYrwyHT MBQQEPE+dCBBuSlygHUj7hbmhmr73FL1K007PaGv5683uiyyE64nWY+NT/n1aPTBv3xV h5zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719125146; x=1719729946; 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=gRou8atfUGeBQZn0IM1Di7dhr7ossIRLfZV52i9gAYE=; b=S39rgDkTwRUm0P5S+j9htyMpbDUXedXoE+U+eymQxAEnyoTwZ1MD6wgjqS5gIcmi1D aX5qXgTrVWnZjcZjhej0djP/K2gbtmHO4ZgyRyW3cqfZZhK7ET2barIWApXZssKtllOy aILW0hDEOdfRv8vWmrihf1HkKjiTEiEbGe6/Ab2H4z+UC6Onc/N0/ghACHL8yo8UCYVK HcDR4VIb3RbeSHcOEi2ZauuoibAorYYYxbY2P+QUhWIcpThshSJnP+c6QPS4Nv+MRUIP fMLsr5yaoFGeRRyr5XvODEaqnc6NQoIXpxR8NDoMZr7NFBfaghYUusqr+hVLdNoRJMRM IE9A== X-Forwarded-Encrypted: i=1; AJvYcCWPxCGJMSTe2Zki6xhA3yLboha9NyXyliO+dq4wsMLfXl6qwhENDgr4GxakSfe89QbpSrS97Ij2BZULOzUimxHz1Mh/ X-Gm-Message-State: AOJu0Yx/M7gz6ZIN5r2zWe0sac6DfcIwnycBlezPzaaQrSu/DRVcS4Ta ApXPOnx7NKwJpr4Qj5qJZ+j4A80WXGf3J1UGqhtVFD8Z8cqksG7XcpGmhA== X-Google-Smtp-Source: AGHT+IH/+tCJlI4oDdR86tiuW2fdjKYKG9gz66knJjFoL9tIKgcEkmCQtqL5iC8+d387qxiVCcTnGw== X-Received: by 2002:a19:a417:0:b0:52c:dc26:465b with SMTP id 2adb3069b0e04-52ce183b261mr702172e87.41.1719125145672; Sat, 22 Jun 2024 23:45:45 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3abd0.dip0.t-ipconnect.de. [79.227.171.208]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6fcf5493dcsm270904766b.134.2024.06.22.23.45.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Jun 2024 23:45:45 -0700 (PDT) In-Reply-To: <864j9kfbm0.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 23 Jun 2024 08:53:59 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::132; envelope-from=gerd.moellmann@gmail.com; helo=mail-lf1-x132.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:320499 Archived-At: Eli Zaretskii writes: > Is it safe to call igc--collect from a non-main Lisp thread? I don't > understand well the semantics and the intent of what igc_collect does, > so I cannot myself try to reason about this. Maybe what we do there > is not safe when invoked from another Lisp thread? Do all our threads > share the same arena, for example? If so, what happens when a Lisp > thread is waiting for the global lock and another Lisp thread calls > igc--collect? igc_collect calls mps_arena_collect which acquires the MPS lock, does a full collection, and leaves the arena in parked state, so that the caller has to mps_release it itself, which we do in igc_collect. This is explicitly only intended for debugging purposes. It is thread-safe. > >> > We must do something about these assertions: when there's an assertion >> > violation caused by a thread which was started by MPS, we cannot call >> > shut_down_emacs in that thread's context, for obvious reasons. We >> > must instead set some flag which will cause the main thread or one of >> > the other Lisp threads call shut_down_emacs. The MPS documentation >> > says: >> > >> > Warning: The installed assertion handler must not call any >> > function in MPS, and it must not access memory managed by the >> > MPS. >> > >> > But our handler, igc_assert_fail, does exactly what they say not to >> > do. >> >> I know. See the comment above that function. > > So how about not calling terminate_due_to_signal from igc_assert_fail? I think igc_assert uses that too, currently, which can fire in various ciscumstances, among them "harmless" ones like for eassert. (Side note: I didn't use eassert because I wanted finer control over assertions in igc.c, for example activating them in igc.c but not the rest of Emacs because of the general slowdown which made using Emacs painful.) In the "harmless" case, it would be nice if Emacs could take some emergency measures, as if it were eassert. Otherwise I was afraid I'd loose my work :-). I also don't find the current behaviour too bad if one knows that further assertion might be triggered if something happens in MPS. If one knows that will happen, of course, hence the comment. And it's all temporary. Hopefully a better solution will be implemented at some point. Maybe one as I described. > >> One idea might be to set aside a block of memory for use when we know >> that MPS is unusable. Then, make alloc_impl allocate from that block, >> and probably we must put MPS in postmortem state. Or maybe we can just >> use malloc in alloc_impl. >> >> I think one should try something like that so that Emacs can do its >> thing as usual in such cases. Can of course fail, and will certainly be >> fiddly. I currently don't have the energy to do that. > > One idea would be to exit the non-main Lisp thread (because I think > shutting down Emacs from there is not safe anyway), then shut down > from the main thread. Yes, maybe. I guess one has to try and see what works best.