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 image cache Date: Sun, 05 May 2024 10:42:58 +0200 Message-ID: References: <875xvvp3fo.fsf@gmail.com> <87o79n0wna.fsf@gmail.com> <87zft4ptaw.fsf@gmail.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="6660"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Emacs Devel To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 05 10:43:43 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 1s3XTD-0001dY-71 for ged-emacs-devel@m.gmane-mx.org; Sun, 05 May 2024 10:43:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3XSf-000151-CV; Sun, 05 May 2024 04:43:09 -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 1s3XSc-00014G-T2 for emacs-devel@gnu.org; Sun, 05 May 2024 04:43:06 -0400 Original-Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s3XSb-00048L-6o; Sun, 05 May 2024 04:43:06 -0400 Original-Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a59a64db066so209873066b.3; Sun, 05 May 2024 01:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714898579; x=1715503379; 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=HbAKEhbkD+T9Cj7mXX7cVuZWmcDUlcbuJFETw4KtPG0=; b=gZfK529I0HP8o747QouB5pfFhU5edPPBBF9XZ/m66hIxni/ewRZ4Z2f+Y1+qEKB9wD jY73tmyPQU/n1MBIQrhxWBQfMcQIc7P0PuDlCxakbIVEBCp/kBy9C+ALdidGGeOGTT5N oahF0z+AAksrGStxYANB0gOROalG/beKtsf4gKboHYgsn4KNMh493WscoH31R4Od14ue qOVIc6JUnhR8UG1mqLSEjGfP/+2uQn4mKuge7t7ipYnka0tBGPsRRE6NKoNMC8zlZahB 6oSNCvoDIJwsi2peFiC7HC+0RNBhc/Jkxd+BPb9o+E2V5DNEM4Uqazu3dm/EaAFvt9Uq SX4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714898579; x=1715503379; 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=HbAKEhbkD+T9Cj7mXX7cVuZWmcDUlcbuJFETw4KtPG0=; b=Bp9iQ3qCLFXA6wX24OnBTCJif4ng+x/8lEHi+cHZDCJpZlLeuCRSSjRViRlKYz+8cj QmWNPPXAjOWPPATvVQsyjA69TiZik/t9WQ8ipS6SUN06WjRslLp4tkJNn+7eGHXhkgWf XP1j8/x7bSf5RwcK+U9hfVnD2Q7wLUufnsg7UVGkZNE3nMgqbbXdwgiVBhyEChhtYHNj ZgL6QD0cbzpn+5EgCKDBup86EZc0oF2L5WHee/JgkK148tLWcIzggWEtP6uunwTemNYX 9y1xmDhf/k+5p4SpCb1mEccfZb+6vvE/7R+bLDwGMAjn9lTCpkYimBEAAqd+7iEYqohZ +vJQ== X-Forwarded-Encrypted: i=1; AJvYcCUlwX48e4ibpMGnp2md5yX5KrZFsiL0WpGNQBbdSQw30TiFLwIbFK1ZPnH4Jl74v/Bwk1IfPolNGVQoHiKWHr7geNrc X-Gm-Message-State: AOJu0YzEOG2RS8+yL2YupOV5O0h1GPGG5pC3GQQ4bYwKClbHdM8bBt/Z 2MUs7SboY3xdiewTJvwzzuPN9yMaGTAI/nHJJZpQmiFZPHySTaNzl1GWSA== X-Google-Smtp-Source: AGHT+IG6d97LPDWaYAzvEDDkEVq1W47vZwpIKAqUOIS4uJckwHY0Ts4ku/zfOEQewU+XNZlnp5xuBw== X-Received: by 2002:a17:907:9722:b0:a59:bae0:b12f with SMTP id jg34-20020a170907972200b00a59bae0b12fmr1565041ejc.57.1714898579522; Sun, 05 May 2024 01:42:59 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a20a.dip0.t-ipconnect.de. [79.227.162.10]) by smtp.gmail.com with ESMTPSA id n1-20020a1709062bc100b00a522fb5587esm3894676ejg.144.2024.05.05.01.42.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 May 2024 01:42:59 -0700 (PDT) In-Reply-To: <87zft4ptaw.fsf@gmail.com> (Helmut Eller's message of "Sun, 05 May 2024 10:16:39 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62c.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:318799 Archived-At: Helmut Eller writes: > On Sun, May 05 2024, Gerd M=C3=B6llmann wrote: > >> I'm plannign to do the following if nobody stops me: >> >> Both face an image cache are hash tables containing 2 arrays of pointers >> to MPS objects (face, image). >> >> I want to introduce a new MPS object type representing such an array of >> pointers, IGC_OBJ_PTR_VEC. The igc_header gives us the size of the >> array, and being an MPS object, we get exclusive access to its contents. >> >> WDYT > > Would something like this also be needed for glyph matrices?=20=20 Probably. Either we make the matrices roots, or objects, I guess. For correctness. We can't easily realloc when they are objects, but I don't think that's a big problem. > Or in general, can we scan anything other than the block that > dflt_scan was called with?=20 Let's say we shouldn't :-). MPS lets us scan memory it doesn't manage, but with multi-threading it's not really safe. > Is these related to "remote references" in the MPS manual, which I > don't quite understand what they mean. That's this A reference that logically belongs to a formatted object and so must be fixed when the object is scanned, but which is not stored within the block containing the object. (For example, in an auxiliary table of some sort.) The MPS does not generally support remote references because those references may be protected and so if scan method attempts to fix them this will hit a barrier (1) and cause a re-entrant call to the MPS. My interpretation of this is that we may only fix12 references withing in an object that is currently scanned (is in the address range for which MPS called us). We may not extend the scan to other MPS objects. Let's say we are scanning a symbol S. The reference to S->name can/must be scanned, but S->name->intervals or something is taboo because S->name may be behind a barrier. Made sense to me.