(this can be used for general discussion of per-thread data) ---- [CMcC] Each of the following [tcl core subsystems] contains Thread Specific Data: * tclFileName * tclIO ([Tcl Core IO System]) * tclNotify * tclAsync * tclEvent * tclTimer * and even tclRegexp It's used, somewhat like ClientData, to store per-thread quasi-global arbitrary data, which is required to maintain state, and used to clean up on termination or [Finalization] as it is called in the [tcl core] This is useful, because it helps modularise each subsystem, however the very encapsulation makes it impossible to extend or modify the subsystems additively, which would make it easier to test subsystem mods without pulling apart entire subsystems. I'm writing a TIP on this subject. ---- [LV] In Jan, 2007, on the [starkit] mailing list, a user asked about problems between [thread]s and [vfs]. [JH] replied that vfs mount points are not shared between threads by design to try to limit easy crash conditions. If a particular vfs mount point is needed, it should be mounted within the thread. As with all packages, once loaded in any interp, they are available statically to all others. hobbit [~] 4 % /Library/Tcl/basekits/base-tcl-thread-macosx-universal % package require Thread 2.6.5 % set t [thread::create {thread::wait}] tid0x1804e00 % package require vfs 1.3 % thread::send $t {load {} vfs} % thread::send $t {package names} Thread tclkitpath zlib vfs Mk4tcl Tcl Unless I'm missing something, this is not sufficient to allow a thread to mount a vfs from within a starpack (Note: I think there's a typo in the message; once loaded libraries are available statically to any interp, put packages are not). In addition to loading the vfs library, a child thread also needs to "package require vfs::mk4". But in a starpack, the vfs::mk4 package resides inside the vfs that the child thread has yet to mount. It's a chicken-and-egg problem. Is there a way to access a vfs from a thread in a starpack? Is there a way to copy the [Thread Specific Data] related to the vfs mounts from one thread to another, thereby duplicating all the mounts in the child thread? Would this work? Are there other cases where having a way to duplicate [Thread Specific Data] might make sense? ---- [Category Threads]