Re: [TCLCORE] Announce: TIP 741: Cleanup of temporary Windows DLL's loaded from zipfs archives

[<apn...@ya...>]

Jan,

I already said, more than once (including in the mail you quoted), that it will be up to someone else who thinks clean up is important enough to request a vote on 741. I also said in that same mail that " The only reason I proposed 741 was because Jan put forth CFV for 709 and one of the arguments he made was no alternative was available.". So, you're pretty much repeating what I already stated.

And as far as being a "game" (whatever that means), I specifically pointed out the actual problems, not easily solvable and not conjecture or "future issues", in your implementation. Something you have not bothered to address at all, either by fixing them or making a case for it's acceptable for Win32 API's to fail in 709 loaded DLL's. Instead, you still think 709 is a solution despite those failures!

And just for the record, for those who are not clear on this, writing of files to disk is not a 741 thing. It already exists in 9.0. 741 only proposes clean up.

/Ashok

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Monday, December 8, 2025 2:46 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Announce: TIP 741: Cleanup of temporary Windows DLL's loaded from zipfs archives

Op vr 5 dec 2025 om 12:09 schreef Ashok:
>Depending on what happens with 709, I won’t even bring 741 to a vote unless someone else feels the cleanup is an issue important enough to solve.

I fear that - if you bring up the vote - people will think this is an
urgent issue to
solve. It isn't. The effect - if 741 is accepted - will be that people
either are forced
even more to link in statically their extension (which they should do anyway, if
possible, so that's a good thing). The other effect will be that people move to
a forked version of Tcl, which works as expected. That's what Christian Werner
is doing. Do we really want that to happen? I don't.

I see TIP #741 as part of a game, with the sole intention of ranting
the TIP #709
implementation. Not as a serious solution which _should_ be in the core.

Sergey wrote:
> But if we speak about deletion, I'd do that in totally different way, like start special deletion child, wait there for parent process end, and only then delete them.
> Better alternative could be a reusable DLL - so creation of DLL in common temporary directory (in cross process mutex) on demand, so it'd be available for all processes of the same version/build-id and don't delete them > at all on exit. That would be a much more sane and faster solution than recreating and deleting DLLs per process every time they start.
That would be my third-best solution (after statically linking and TIP #709)

Let's see what happens.

Regards,
     Jan Nijtmans


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core