the current tclkit-lite builds (by means of kbs) cannot load any packages
inside a thread.
1. the auto_path is not promoted, but I think this is intentional
2. the vfs-filesystem is not known inside the thread
3. the pkgIndex.tcl files alongside the auto_path dirs are not loaded inside
the thread
My first workaround for 3. with an unpackaged vfs was to explicitly load the
required pkgIndex.tcl (for I only use one package inside the thread). But
this doesn't work in the starkit nor in a starpack.
I vaguely remember some discussion, but don't remember where and with what
subject, that the initialization code for interpreters is flawed in
tclkit-lite. Is there a fix or someone working at it? Where do I have to
start, to make a fix myself?
Sincerly
Uwe Koloska
--
Dipl.-Ing. Uwe Koloska
voice INTER connect GmbH Tel +351 481 088 3
Ammonstraße 35 Fax +351 438 399 25
01067 Dresden - Germany www.voiceinterconnect.de
On 12 Jul., 13:55, Uwe Koloska <kolo...@voiceinterconnect.de> wrote:
> I vaguely remember some discussion, but don't remember where and with what
> subject, that the initialization code for interpreters is flawed in
> tclkit-lite. Is there a fix or someone working at it? Where do I have to
> start, to make a fix myself?
I have found this discussion: It is an old thread on this list
starting on 2007-01-02 with the subject "starpack vfs can't be
accessed from thread". But the fix that is presented by Jeff Hobbs
ist already included in the boot.tcl and the provided threadvfs
procedure that starts a new thread with the vfs mounted doesn't work
-- maybe because it was not meant for a starkit-lite without a proper
mk4 database engine.
What I understand now, ist that it is by intention, that a thread has
not the same vfs mount then the main thread.
But what is the recommended way to load a package inside a thread?
The only reason I have to use threads (yes, I know the discussion
about threads, being evil ;-) is a c-based package (fluidsynth, if you
care) that uses threads, because callbacks from this thread create big
troubles, if they used to trigger Tk functions -- but this is another
story and told inside another discussion ;-)
Sincerly
Uwe Koloska
There are some issues still with the initial startup code. Its been a
while but if I remember correctly I found the internal packages were
not always available in slave interpreters and this is likely the same
in thread interpreters. I currently use a modified kitInit.c as
attached. This drops the preInitScript in favour of using the full
appInit script as was done in the old tclkits. Possibly this will help
you -- seems to work ok for me.
Pat Thoyts
Am Montag, 16. Juli 2007 schrieb Pat Thoyts:
> There are some issues still with the initial startup code. Its been a
> while but if I remember correctly I found the internal packages were
> not always available in slave interpreters and this is likely the same
> in thread interpreters. I currently use a modified kitInit.c as
> attached. This drops the preInitScript in favour of using the full
> appInit script as was done in the old tclkits. Possibly this will help
> you -- seems to work ok for me.
Yes, this works. At least the internal packages are available. But the vfs
is still not mounted (I think this is due to the thread safety problem). A
simple
package require starkit
starkit::startup
doesn't mount the vfs (or at least not with the same path).
How can I load packages from the vfs inside the thread?
The threadvfs proc from the earlier mentioned thread doesn't work anymore.
Thank you for any help
Uwe Koloska
have you ever found the solution to this problem?
I have a similar problem here.
I want to package a threaded application as starpack, but none of my threads have access to the Tcl packages within the app's vfs then.
//Hermann