Joe English wrote:
> For instance: if you just want to load a DLL for preloading purposes
> you need to pass 3 dummy NULL pointers to Tcl_LoadFile();
> conversely if you want to load multiple procedure tables from
> a single shared library you either have to reimplement half
> of Tcl_LoadFile() by hand or open the shared library multiple times.
Huh? The load handle is still open, and Tcl_FindSymbol is also
exported in the ccurrent version of the TIP. It's not *that* hard
to do a trivial loop with Tcl_FindSymbol calls. One convenience of
combining the two pieces is, as you pointed out earlier, that
(given the fact that it now fails if one or more symbols are not
found) it cleans up after itself on failure.
In any case, I wanted to make the common use case (load a shared
library, resolve a few symbols in it, and then forget about it
and let process exit clean up) to be a single call.
> Suggested interface:
>
> EXTERN Tcl_LoadHandle * /* [note 1]
> Tcl_LoadFile(
> Tcl_Interp *interp, /* optional; for error reporting */
> const char *pathName, /* [note 2] */
> unsigned flags); /* [note 3] */
>
> EXTERN int
> Tcl_LoadProcedures(
> Tcl_Interp *interp, /* optional; for error reporting */
> Tcl_LoadHandle *, /* returned from Tcl_LoadFile */
> const char *symbols[], /* NULL-terminated [note 4] */
> void *procPtrs);
>
>
> [note 1]: Instead of returning an int (which is always TCL_OK or
> TCL_ERROR) and storing the load handle in an "out" parameter,
> suggest returning the load handle directly, using NULL to signal
> an error.
Hmm. I tend to use the integer status when there is more than one
'out' parameter, but I suppose I could consider that.
> [note 2]: Suggest passing the path name as a 'const char *'
> instead of a Tcl_Obj *. Rationale: in the common case,
> the name of the shared library to load is a compile-time
> constant, and it's less work to get a 'const char *' out of
> a Tcl_Obj* than it is to build a Tcl_Obj* from a const char *.
Maybe. I was thinking of Tcl_LoadFile as a Consumer of the
file name, and ISTR that there are platform-native implementations
that need to hold onto it.
> [note 3]: With reluctance: you'll probably want a flags argument.
> Not needed now, but there's a better-than-average chance that
> it'll be needed in future; adding it now will head off the
> need for a future Tcl_LoadFileEx(). (Possible enhancements
> that people are likely to ask for: use equivalent of RTLD_GLOBAL;
> *don't* use equivalent of RTLD_GLOBAL; ...)
Eeeeew. You're probably right, but... eeeeew.
> [note 4]: Instead of separate 'symc' and 'symv' parameters,
> let 'symv' be a NULL-terminated array. Don't make programmers
> count.
You said that before. I don't mind that much using
sizeof(symv)/sizeov(*symv)
>
> Also worth considering: following the rule of thumb "don't
> check for errors that you can't do anything about", consider
> changing Tcl_FSUnloadFile() to:
>
> EXTERN void Tcl_UnloadFile(Tcl_LoadHandle *);
Oh, but I can: in the case on Windows where I can't unload the
file because someone is still using it (and therefore can't
remove a copy-vfs-to-native file), I can launch a subprocess
to clean it up after I exit.
|
