On Fri, Feb 01, 2019 at 11:44:45AM +0100, Zoran Vasiljevic wrote: > The only safe way to share data between threads > in Tcl is over strings. One can go to some extent > and try making Tcl objects shareable but for that > you need to know the object internals which is a > great PITA and does not always work well, except for > a limited set of object types.
What if you don't care much about Tcl objects? A C pointer is already easily shareable across threads (you just need the proper mutex locking when using it), the trick is finding it again using some handle from Tcl. For simplicity, should I just completely ignore the whole Tcl_Obj machinery when doing that? Or SHOULD I (always?) make my handle into a Tcl_Obj? If so, can you go into a bit more detail on WHY that's a better approach? Even despite the fact that this Tcl_Obj thing is now more difficult to share across threads? If I take an ordinary sort of Tcl string or integer and hand it to my C code, that works fine as the key for an nsv or Tcl_HashTable lookup. Of course, the code doesn't "know" that that particular string is supposed to be a handle, but there's nothing stopping me from simply using it as one in the C code, and throwing an error if I can't find a hash entry for it. I suspect that the above is NOT the recommended approach, but I don't fully understand why. It seems "simpler" to me... But maybe that's only because I don't yet understand the Tcl_Obj integration approach, and what benefits it provides. On Fri, Feb 01, 2019 at 10:29:47AM +0100, Zoran Vasiljevic wrote: > You might want to look into: > > nsd/tclobj.c Hm, that has Ns_TclSetTwoPtrValue(), Ns_TclGetOpaqueFromObj(), and other black magic (or so it seems to me). Are there docs on these C APIs anywhere? Some of the stuff in "nsd/tclobj.c" seems be primarily concerned with the "address object type" (IP addresses?), but I get the sense that much of that code is much more general purpose than that. I see that "nsd/tcltime.c" uses the tclobj.c functions to implement an Ns_Time Tcl_Obj type, but I definitely don't understand how or why yet! -- Andrew Piskorski <a...@piskorski.com> _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
