Re: Re: starkit-lite and threads: can't package require
Hermann Boeken <[email protected]> Wed, 22 Aug 2012 01:26:54 -0700 (PDT)
| Newsgroups | gmane.comp.lang.tcl.starkit |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_1551_17251851.1345624014958 Content-Type: text/plain; charset=ISO-8859-1 Am Montag, 16. Juli 2007 23:33:22 UTC+2 schrieb [email protected]: > > On 16/07/07, Uwe Koloska <[email protected] <javascript:>> wrote: > > > > Hello again, > > > > On 12 Jul., 13:55, Uwe Koloska <[email protected]> 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 ;-) > > 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 > Hello Pat, is there also a patch available for the current version of kitgen (patthoyts-kitgen-273ad4c)? //Hermann -- You received this message because you are subscribed to the "starkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/starkit?hl=en ------=_Part_1551_17251851.1345624014958 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br>Am Montag, 16. Juli 2007 23:33:22 UTC+2 schrieb [email protected]:= <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor= der-left: 1px #ccc solid;padding-left: 1ex;">On 16/07/07, Uwe Koloska <<= a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Oaim34mX1= b0J">[email protected]</a>> wrote:<br>><br>> Hello again,<br>><b= r>> On 12 Jul., 13:55, Uwe Koloska <<a>[email protected]</= a>> wrote:<br>> > I vaguely remember some discussion, but don't re= member where and with what<br>> > subject, that the initialization co= de for interpreters is flawed in<br>> > tclkit-lite. Is there a= fix or someone working at it? Where do I have to<br>> > start,= to make a fix myself?<br>><br>> I have found this discussion: = It is an old thread on this list<br>> starting on 2007-01-02 with the su= bject "starpack vfs can't be<br>> accessed from thread". But the f= ix that is presented by Jeff Hobbs<br>> ist already included in the boot= .tcl and the provided threadvfs<br>> procedure that starts a new thread = with the vfs mounted doesn't work<br>> -- maybe because it was not meant= for a starkit-lite without a proper<br>> mk4 database engine.<br>><b= r>> What I understand now, ist that it is by intention, that a thread ha= s<br>> not the same vfs mount then the main thread.<br>><br>> But = what is the recommended way to load a package inside a thread?<br>><br>&= gt; The only reason I have to use threads (yes, I know the discussion<br>&g= t; about threads, being evil ;-) is a c-based package (fluidsynth, if you<b= r>> care) that uses threads, because callbacks from this thread create b= ig<br>> troubles, if they used to trigger Tk functions -- but this is an= other<br>> story and told inside another discussion ;-)<p>There are some= issues still with the initial startup code. Its been a<br>while but if I r= emember correctly I found the internal packages were<br>not always availabl= e in slave interpreters and this is likely the same<br>in thread interprete= rs. I currently use a modified kitInit.c as<br>attached. This drops the pre= InitScript in favour of using the full<br>appInit script as was done in the= old tclkits. Possibly this will help<br>you -- seems to work ok for me.<br= >Pat Thoyts<br></p></blockquote><div><br>Hello Pat,<br><br>is there also a = patch available for the current version of kitgen (patthoyts-kitgen-273ad4c= )?<br><br>//Hermann<br></div> <p></p> -- <br /> You received this message because you are subscribed to the "starkit&q= uot; group.<br /> To post to this group, send email to [email protected]<br /> To unsubscribe from this group, send email to starkit-unsubscribe@googlegro= ups.com<br /> For more options, visit this group at <a href=3D"http://groups.google.com/g= roup/starkit?hl=3Den">http://groups.google.com/group/starkit?hl=3Den</a> ------=_Part_1551_17251851.1345624014958--