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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.