On Thu, 16 Mar 2000, Jiang Wu wrote:

Yeah, you are right about that. The Shell class really should not be
calling those methods from other threads. I think it "just works" in
Jacl because Jacl uses lots of Hashtable objects in its implementation
and those are always thread safe (which is a bug not a feature). Tcl
Blend is much more likely to crash if threads are walking over each other.

> Looking over the Jacl's tcl.lang.Shell source code, there are several places
> where the ConsoleThread is accessing the tcl.lang.Interp object's method.
> For example, the ConsoleThread's run() method makes calls to:
> 
>       interp.getVar(...);
>       interp.setVar(...);
>       interp.updateReturnInfo();
>       interp.getResult();
>       interp.eval();
> 
> These calls shouldn't be made by the ConsoleThread since the ConsoleThread
> is not the event loop thread running the interpreter.
> 
> The interesting thing about this code is that it is convenient for a
> programmer to call the methods in the tcl.lang.Interp class directly from
> any thread without going through the process of queuing up a TclEvent on the
> Notifier.

This is an interesting idea. I think the "thread safe Interp" class
would need to be called something that would make it very clear that
each of the calls was "slow". I worry that if people read that
TclInterp is thread safe but Interp is not, they would just go using
TclInterp without thinking about some of the consequences (If java
have proven anything, it is that threads should not be used for most
general programming tasks).

Mo DeJong
Red Hat Inc.

> The Notifier class and the Interp class together make it possible to use Tcl
> from a multi-threaded Java environment using an event queue model.  It may
> also be useful to have another class, or extending the existing Notifier
> class, to use the Notifier's event queue to provide a function call
> interface to the methods in the Interp class.
> 
> For example:
> 
> tcl.lang.Interp        - used by a single thread only
>   eval(), 
>   setAssocData(),
>   deleteAssocData(),
>   setVar(), 
>   getVar(),
>   etc.
>   
> tcl.lang.Notifier      - used by multiple threads through "queueEvent()"
>   queueEvent()
>   serviceEvent()
>   etc.
> 
> tcl.lang.TclInterp     - uses Notifier's event queue to invoke Interp's
> methods...
>   eval(),
>   setAssocData(),
>   deleteAssocData(),
>   setVar(),
>   getVar(),
>   etc.
> 
> Then, the Jacl ConsoleThread can do something like:
> 
>     void methodFooBar (Interp interp) {    
>         Notifier notifier = interp.getNotifier();
>         TclInterp tclInterp  = notifier.getTclInterp();
> 
>         tclInterp.eval(...);
>         tclInterp.setVar(...);
>     }
> 
> Of course, having this extra class is not absolute necessary.  It is only a
> convenience.
> 
> -- Jiang Wu
>    [EMAIL PROTECTED]
> 

----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:    send mail to [EMAIL PROTECTED]  
                 with the word SUBSCRIBE as the subject.
To unsubscribe:  send mail to [EMAIL PROTECTED] 
                 with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'. 
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com

Reply via email to