Re: sample extension: how to beam created proc tolkens to unload procedure

Am 10.12.2024 um 17:37 schrieb Emiliano:

On Tue, 10 Dec 2024 17:11:08 +0100
Harald Oehlmann <wortkarg3@yahoo.com> wrote:
 

Am 10.12.2024 um 16:13 schrieb Emiliano:

On Tue, 10 Dec 2024 10:35:46 +0100

Sample_Init:
struct CmdClientData *cmdClientDataPtr;
cmdClientDataPtr = ckalloc(sizeof(struct Sha1ClientData));

-------------------------------------------^
Shouldn't this be "struct CmdClientDataPtr"?

>
Yes, good catch
>

cmdClientDataPtr->sha1CmdTolken = Tcl_CreateObjCommand(
    interp, "sha1", (Tcl_ObjCmdProc *)Sha1_Cmd,
               sha1ClientDataPtr, Sha1_CmdDeleteProc);

---------------^
Shouldn't this be "cmdClientDataPtr"?

>
Well, I use a client data for the command "sha1ClientDataPtr" with the
command state, which is deleted by the command delete proc
"Sha1_CmdDeleteProc".
>
In addition, there is assoc data of the dll "cmdClientDataPtr" to keep
the command tokens for removal within the unload procedure.
>
Is this design sensible ?

 Can't say without seeing the real code, but ...
 * If you delete the command [sha1], either using [rename] or by deleting
   the current interpreter or namespace, you might want to unload the
   library as well, and free all allocated resources;
* If you [unload] the library, you might want to also delete the [sha1]
   command, and free all allocated resources.
* If you are using Tcl_{Get|Set}AssocData, you have to check the right
   time to use ckfree if both cleanup functions depends on clientdata
   to be valid. In this case, Tcl_Preserve/Tcl_Release and
   Tcl_EventuallyFree might be useful. Or maybe adding a flag in the
   clientdata structure to mark "This cleanup function was already been called".
 

>
THanks for all,
Harald

 Regards

Hi Emiliano,
thanks, great !
Here is the current proposal:
https://core.tcl-lang.org/sampleextension/file?name=generic/tclsample.c&ci=tip
I thought, that the command client data is really tied to the command.
And the clean-up is called on command deletion. That is easier, as there is the clientData pointer at each command interaction (Call, Deletion).
I think, assoc data has only be used for commands, if the data should be available outside of those interactions, like event processing.
Here, this is not the case.
But it may be added as a comment.
About the DLL, the unload or interpreter destruction should care.
To unload the DLL by "rename sha1 {}" would be an incredible feature I don't want to think of. Users may use "unload <PathToDll>" to do so.
Thanks for all,
Harald