From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Native module callback when Lisp thread exits Date: Fri, 17 May 2024 21:26:59 +0300 Message-ID: <86msoofg5o.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7764"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, mshinwell@janestreet.com To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 17 20:28:16 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 1s82JS-0001lV-La for ged-emacs-devel@m.gmane-mx.org; Fri, 17 May 2024 20:28:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s82Ia-0008Ka-0U; Fri, 17 May 2024 14:27:20 -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 1s82IK-0008Dg-2b for emacs-devel@gnu.org; Fri, 17 May 2024 14:27:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s82II-0002bk-Iy; Fri, 17 May 2024 14:27:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Yj5w5y6SHQ8bX1JcnyCgkwpTPOBwxf/QhvHnGHlrI1A=; b=foH5Dn5YbbUK QslllHPcjdRxfP9Y6cOac7pwE2u2zCMT0b88zek1WEYBpkAJqjRCcc6javH84UFmvF34ZI4XitBTl nHKSSGCmQgbFgMin9hmpXGz/yuoJoFBv5RFjjmRHji6d39APNprN9N7RjAiVTeWp32zHKT5Ul5Dmm oxS+QD7gkEHKEvf5lQMMerTEEEgYVLALF98jG8KfDqJmo9QHn8cyW1xasvHlK4AldxRmpeYGD9CHQ AOIE7CJHEj/FJDKwUWp2TLczWDWiFVUzqOhkvoaC/QilXswOlX22c4SmSAui8lF/NYKcqXThJfg3a mIqe3b+PYhW3J7BvS9NOAA==; In-Reply-To: (message from Spencer Baugh on Fri, 17 May 2024 13:09:35 -0400) 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:319333 Archived-At: > From: Spencer Baugh > Date: Fri, 17 May 2024 13:09:35 -0400 > Cc: mshinwell@janestreet.com > > I have a native module written in OCaml which provides some useful > functions. Sometimes, I would like to call these native module > functions from Lisp threads other than the main Lisp thread. > > For a native module written in C, this works fine. However, the OCaml > runtime requires that if it's called from other threads, the thread must > first call caml_c_thread_register; and when the thread exits, it should > call caml_c_thread_unregister. See > https://ocaml.org/manual/5.1/intfc.html#ss:c-thread-register > > My native module can call caml_c_thread_register when the native module > is first called in a non-main thread; then calling my native module > functions works fine in Lisp threads. > > However, there's no way for my native module to call > caml_c_thread_unregister when the thread exits. That causes memory > leaks and means that OCaml GC performance degrades over time, since the > GC scans all known threads. > > Could we add a way for a native module to call some functions when a > Lisp thread exits? > > Currently, native modules expose a emacs_module_init function which is > called when the module is loaded. Maybe a native module could > optionally also expose an emacs_module_thread_init function which is > called when a Lisp thread is created (or maybe when the module is first > used on a Lisp thread). And likewise, an emacs_module_thread_uninit > function which is called when a Lisp thread exits. I don't understand why you need something module-specific. Shouldn't a thread-exit-hook be enough? We could easily add that if that helps.