On 2002.05.04, Andrew Piskorski <[EMAIL PROTECTED]> wrote: > On Sat, May 04, 2002 at 01:31:42AM -0400, Dossy wrote: > > Could you not call NsTclVSetCmd() yourself? Look in > > nsd/tclvar.c ... > > Hm. NsTclVSetCmd() does stuff to or with the Tcl interpretor, and I > don't HAVE any convenient local "interp" pointer in my C function to > pass is. Should I be passing the interp pointer into my C function, > so I can use it for things like NsTclVSetCmd()?
Yes. That's what I would do. > But then, I should check the return value in the Tcl interp or > something to figure out what actually happened? I dunno. (Clearly > though, that wouldn't be any worse than the non-existant error > checking I have in my BB_NsvSet() using Ns_TclEval() right now.) If you're not passing the interp to Ns_TclEval to tell it in which interpreter to perform the TclEval ... then don't you wonder which interp it's using? > Basically, I don't understand why NsTclVSetCmd() is implemented the > way it is, rather than as a pair of two functions: > 1. NsVSetCmd() function for use by C which does not use any Tcl > interp at all. > 2. NsTclVSetCmd() which implements the nsv_set Tcl command and calls > NsVSetCmd() to do the actual work. You need to grab a lock for the particular interp and its thread. That implies to me that you need to be able to specify the interp. Or, maybe you're right and my understanding of the nsv implementation is wrong. Entirely possible. I do think that the "meat" of the actual nsv C code should be refactored into a NsVSetCmd() or something similar, but if it isn't safe to call directly, then perhaps that's a valid reason not to refactor it out -- to prevent people from calling it wrong. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
