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: MPS: Win64 testers? Date: Fri, 23 Aug 2024 16:08:07 +0300 Message-ID: <8634mvqte0.fsf@gnu.org> References: <87bk1k8mzd.fsf@protonmail.com> <861q2gs8xu.fsf@gnu.org> <877cc88j4p.fsf@protonmail.com> <86seuvre6x.fsf@gnu.org> <8734mv8yb6.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34037"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 23 15:08:59 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 1shU2E-0008f3-4t for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Aug 2024 15:08:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1shU1W-0000NG-VH; Fri, 23 Aug 2024 09:08:15 -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 1shU1V-0000My-Dy for emacs-devel@gnu.org; Fri, 23 Aug 2024 09:08:13 -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 1shU1U-0007Rl-VK; Fri, 23 Aug 2024 09:08:12 -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=oBc8WdIMnlWKGu/4lt1fpJFRO9x4JDQ0bs83LCq1Z+4=; b=AJ/e1mqB9xPq zuXQqqplkxOJWS5I9+p+F9pbHKLOvCHR5a4OSuVYWfLSkhe5YUhtw/FQTkl/Q/Bo9mZP5bBoKU2zV M8XFwlETgdj1/hKq42pXUrQ2H0HWP3RAtPVNufhohzOfmZNjDTQFt7J3GgL0h30S8xXiyV5LUx4+W avgsaOQq4TGR3WWDW4KEBejsyiU0YHgdfMVgZw1baEh5YvPVqFoG5Qr3f5Q/nUogr6VMwZBTNXN/L wSjTiII+9UY+U1/P1kgc8RBBkOvy8xFyR5d2JNKNHbZGo2rI+dAcmGeKs+PL+6HdDcwP7vWqUDw4I q7LT4ejaDjjPtIp4CRjksQ==; In-Reply-To: <8734mv8yb6.fsf@protonmail.com> (message from Pip Cet on Fri, 23 Aug 2024 07:59:13 +0000) 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:323083 Archived-At: > Date: Fri, 23 Aug 2024 07:59:13 +0000 > From: Pip Cet > Cc: sebastian@sebasmonia.com, kien.n.quang@gmail.com, emacs-devel@gnu.org, yantar92@posteo.net > > >> That hands a pointer to 'proc' to gnutls, and if 'proc' subsequently > >> moves, emacs_gnutls_push or emacs_gnutls_pull will try to dereference a > >> stale pointer. > > > > But the pointer to 'proc' is passed to GnuTLS for the sole purpose > > that GnuTLS passes it back to our callback, emacs_gnutls_pull. GnuTLS > > itself does not (and cannot) use that pointer, for the obvious reasons > > that it knows nothing about our objects. > > That is my understanding as well. I'm not sure why you think that's a > "but", though. Because you seemed to say we were passing the object to GnuTLS for its own use. > A pointer to memory managed in a copying pool, stored outside of > MPS-managed memory, as 'proc' presumably is (in malloc()ed memory, I > would guess, or maybe in a static location somewhere), must be pinned > somehow, so MPS does not move it during GC. Then let's pin it. But my bother is that we will need to similarly pin many other pointers and objects, or risk segfaults. Maybe it means that MPS and similar igc systems are not suitable for Emacs. > > And what do you mean by "asynchronous calls"? For example, you can > > see in w32font.c that we call certain Windows APIs which work by > > enumerating objects of some kind and calling our callback for each > > such object (the callback that does with each object what it needs to > > do). Is this an "asynchronous call"? If not, what is? > > It doesn't look asynchronous to me, though I'm not sure we're talking > about the same code. The LPARAM arguments referring to stack locations > are fine, because the stack is known to MPS. I mean this: EnumFontFamiliesEx (dc, &match_data->pattern, (FONTENUMPROC) add_font_entity_to_list, (LPARAM) match_data, 0); where add_font_entity_to_list is our callback which is called for every font family and decides whether it matches the font spec; if so, the callback adds the family to a list that is then used by the caller of EnumFontFamiliesEx. > The problem here is that 'proc' might move. One solution is to make the > cookie a pointer to memory known to MPS, which contains the actual > pointer to the Lisp_Process. Note that it is not strictly necessary for > the pointer to be allocated with igc_xzalloc_ambig, we could use the > _raw_exact variant. Why not tell MPS not to move this pointer instead? It sounds like a simpler solution than the change you proposed. The solution you propose will complicate large parts of the Emacs code by using double indirection; pinning a pointer is much simpler. Or am I missing something? > There are other solutions which may be better. I certainly hope so, since auditing all of our sources for such gotchas is an impossible job.