RE: starpack vfs can't be accessed from thread
"Jeff Hobbs" <[email protected]>
| Newsgroups | gmane.comp.lang.tcl.starkit |
|---|---|
| Organization | ActiveState |
| Message-ID | <[email protected]> |
[email protected] wrote: > However, while this enables the thread to access the vfs, the > package mechanism does not find packages inside the vfs from > within the new thread. If you cd into the directory > directly, files can be "source"'d from the thread so the vfs > is (sort of) working. I'm setting the auto_path variable for > the thread, is there anything else that's necessary to get > the package mechanism to work? Thanks for continuing to bang your head against this. I have now identified the issue. It was a follow on complication from the changes to vfs to make it thread-safe (which meant mount points are no longer shared between threads). This requires a change in the starkit boot.tcl for how it determined whether to mount the exe for access. It previously used a check that wasn't really mount-info based, but made sure it only occured once per process. I have modified it to do the mount anytime it doesn't exist. This guards against any future eventuality that the mount is re-shared in threads, or even possibly that each individual interp must remount the exe. The patch is: @@ -11,8 +11,11 @@ # get rid of a build residue unset -nocomplain ::tclDefaultLibrary < # the following code only gets executed once on startup < if {[info exists tcl_rcFileName]} { -> # The following code only gets executed if we don't have our exe -> # already mounted. This should only happen once per thread. -> # We could use [vfs::filesystem info], but that would require -> # loading vfs into every interp. -> if {![file isdirectory $noe]} { load {} pwb load {} vfs You can modify this in the existing 8.4.14 basekit that you have. We will have it corrected as well in the next release. > (8.4.13) when it crashed. Perhaps there's still something in > the vfs code that's not thread-safe? Possibly. I had clear conditions to make it crash before, and those are all addressed. The vfs C code no longer has any global vars being used, but that doesn't mean something else isn't amiss. Please let me know if you have a reproducable test case. Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/