Re: [BUG] temporary file usage report with extended protocol and unnamed portals

On Thu, Sep 11, 2025 at 10:28:50AM -0500, Sami Imseih wrote:
> > Only question is if we should avoid the extra portal hashtable lookup as well, or leave that for a separate patch.
> 
> I prefer a separate thread for this, as it's an optimization of the
> existing behavior.

-		portal = CreatePortal("", true, true);
+		if (!unnamed_portal)
+			portal = CreatePortalOnly("");
+		else
+			portal = CreatePortal("", true, true);
[...]
-CreatePortal(const char *name, bool allowDup, bool dupSilent)
+CreatePortalOnly(const char *name)
+Portal
+CreatePortal(const char *name, bool allowDup, bool dupSilent)

Talking about v9 here, as far as I can see.  I don't think that it is
a wise idea to create a new API for this layer, while duplicating two
times the same pattern where the old CreatePortal() function and the
new CreatePortalOnly() function are called.  CreatePortalOnly() is
called by CreatePortal(), adding to the confusion.  If we refactor
this API, it may be an idea to use a bits32 with two flags rather than
two booleans, especially if we justify a third boolean case.  That
would make CreatePortal() more solid on ABI grounds in the long-term,
as well.

Just my 2c while looking at this particular part of the thread.  Now
to the main patch proposed, v8 or v10..
--
Michael