On Sat, May 04, 2002 at 11:06:09AM -0400, Dossy wrote: > On 2002.05.04, Andrew Piskorski <[EMAIL PROTECTED]> wrote: > > On Sat, May 04, 2002 at 01:31:42AM -0400, Dossy wrote:
> 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? Um... I admit that never occurred to me. Ah, Ns_TclEval calls Ns_TclAllocateInter, which in this case should be returning the interpretor for my current thread, which is fine. But your suggestion to NsTclVSetCmd() directly definitely sounds like a better idea. > 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 haven't studied the tclvar.c much, but why would nsv locks have anything to do with threads at all? The nsv data structures are server-wide, after all, so I don't THINK there's anything per-thread or per-interp about them at all. It isn't obvious to me how those data structures are really set up though. There're the "Bucket" and "Array" struct typedefs, and then the "static Bucket *buckets" array, but I'm not entirely clear on how they all actually interact. > 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. I don't THINK there's any reason it wouldn't be safe to call the re-factored C functins directly. And I'd be willing to do the refactoring - not right now but sometime. So if somebody who really understands this can give some guidance on the locking and design questions Dossy raised, I'd appreciate it. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com
