Itcl and TIP#257
Arnulf Wiedemann
I have done a relatively detailed proof of concept implementation for Itcl
based on the functionality provided by the TIP#257 implementation available
at sourceforge. The general strategy used is: use as much of the TIP#257
implementation as possible (with perhaps some extensions), use a small
resolver (had to be written in C) for the namespace/method/variable
resolution used by Itcl and use a Tcl written Parser for converting the
itcl::class etc. syntax to the syntax provided by TIP#257.
The implementation succeeded and and I am able to run some simple Itcl
programs which are using the simpler parts of the syntax. I can create a
hierarchy of classes, instantiate them and call member methods according to
the protection rules of Itcl. There can be variables defined with the
protection keywords for Itcl and if used and modified these are handled
correctly according to the Itcl rules.
As the way taken seems to promise success for a full implementation, I will
continue.
Comments are welcome.
Arnulf
Eckhard Lehmann
Arnulf Wiedemann wrote:
> for those, who are interested:
>
> I have done a relatively detailed proof of concept implementation for Itcl
> based on the functionality provided by the TIP#257 implementation available
> at sourceforge. The general strategy used is: use as much of the TIP#257
> implementation as possible (with perhaps some extensions), use a small
> resolver (had to be written in C) for the namespace/method/variable
> resolution used by Itcl and use a Tcl written Parser for converting the
> itcl::class etc. syntax to the syntax provided by TIP#257.
> As the way taken seems to promise success for a full implementation, I will
> continue.
>
> Comments are welcome.
Nice to see...
2 questions:
- How are threads handled in TIP 257 and in your implementation? Is it
(planned to be) possible to share objects between threads?
- Is Itk possible as well?
Eckhard
Arnulf Wiedemann
I am not so familiar with threads, but as far as I have understood it should
be possible, better ask DKF for that.
It should be possible for my implementation (it's anly about 500 lines of
code in C, which is operating on the stack only).
If the main thing is that it is reentrant and does not use global or static
variables in C, then the answer is yes.
Concerning shared objects: at least in my implementation it is not possible
at the moment, but I assume it could be done.
> - Is Itk possible as well?
Itk is 2nd step :)
I hope so. I don't know if there is a lot of C-code for itk and what the
functionality is in detail (so I am using it in my programs a lot). What I
know is, there is the need for an itk_option define command, which should
be possible to implement. Maybe you or somebody else could give me some
hints on what is needed there. (did not yet have time to look into that).
Arnulf
>
>
> Eckhard
Donal K. Fellows
> - How are threads handled in TIP 257 and in your implementation? Is it
> (planned to be) possible to share objects between threads?
Objects are *strictly* bound to a single interpreter (for a whole bunch
of reasons). If you wish to create proxy objects in other interpreters
(including in other threads) that perform RPC-like calls to the master
object, that's quite possible. Outside the scope of what I'm doing
though.
> - Is Itk possible as well?
No idea. :-)
Donal.
Eckhard Lehmann
Donal K. Fellows wrote:
> Eckhard Lehmann wrote:
> > - How are threads handled in TIP 257 and in your implementation? Is it
> > (planned to be) possible to share objects between threads?
>
> Objects are *strictly* bound to a single interpreter (for a whole bunch
> of reasons).
Can you name some of this reasons?
In my opinion it is necessary to have objects shared among threads to
access/change them simultaneously. I have implemented this for Itcl and
it works quite good...
http://e-lehmann.de/index.php/tcltk/itcl-and-threads/.
Eckhard
Don Porter
> Donal K. Fellows wrote:
>> Eckhard Lehmann wrote:
>>> - How are threads handled in TIP 257 and in your implementation? Is it
>>> (planned to be) possible to share objects between threads?
>> Objects are *strictly* bound to a single interpreter (for a whole bunch
>> of reasons).
>
> Can you name some of this reasons?
How about the obvious? An "object" is a command. Every command
is registered in exactly one interp.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Eckhard Lehmann
Don Porter wrote:
> > Can you name some of this reasons?
>
> How about the obvious? An "object" is a command. Every command
> is registered in exactly one interp.
That's not obvious: Create a command for the _same_ object in every
interpreter.
During deletion in an interp, only delete the command unless there is
only one command left - in this case, destroy the object as usual.
Eckhard
MH
Don Porter
> Don Porter wrote:
>>> Can you name some of this reasons?
>> How about the obvious? An "object" is a command. Every command
>> is registered in exactly one interp.
>
> That's not obvious: Create a command for the _same_ object in every
> interpreter.
It's not at all clear to me what benefits it would bring to have
magical multi-interp commands.
It is quite clear to me that sorting through all the issues such beasts
would raise would be a huge pile of work, to say nothing of implementing
them.
Donal can supply the other reasons he has in mind, if he's so inclined.
Eckhard Lehmann
Don Porter wrote:
> > That's not obvious: Create a command for the _same_ object in every
> > interpreter.
> It's not at all clear to me what benefits it would bring to have
> magical multi-interp commands.
Access to the object in every interpreter. That's the benefit.
> It is quite clear to me that sorting through all the issues such beasts
> would raise would be a huge pile of work, to say nothing of implementing
> them.
What issues do you think of?
AFAIK, a command to just access the object works in one interp as well
as in a second or the 100. interpreter. The only issues I can think of
are related to synchronisation of the object data - and this can be
solved (in fact, it is solved in my enhanced Itcl).
> Donal can supply the other reasons he has in mind, if he's so inclined.
Hopefully he is :). Of course I might be wrong or naive regarding this
subject...
Eckhard
Don Porter
>> It is quite clear to me that sorting through all the issues such beasts
>> would raise would be a huge pile of work, to say nothing of implementing
>> them.
>
> What issues do you think of?
Currently, when I create the [foo] command, it overwrites any existing
[foo] command in my interp. It's assumed I know what I'm doing.
With magical multi-interp commands, I'd overwrite every [foo] command in
every interp? Including those I'm doing no business with at all?
Much more along similar lines. Interp isolation is a feature, not a
bug. Deep, deep hairy issues here. Tcl interps ain't designed that way.
Andreas Leitgeb
> Currently, when I create the [foo] command, it overwrites any existing
> [foo] command in my interp. It's assumed I know what I'm doing.
>
> With magical multi-interp commands, I'd overwrite every [foo] command in
> every interp? Including those I'm doing no business with at all?
>
Being neither threads- nor itcl-expert, this leaves the
question, whether it is (at least) possible to explicitly
share an object between two interpreters.
Likely one can do so with interp alias, but this
would mean one interpreter is still the master:
semantics like symlinks in unix-filesystem. Is
there a way to establish semantics like hardlinks?
That is:
interp1 creates an object,
it gets (through program logic) shared to interp2
both use it
interp1 removes it's reference to it,
interp2 continues using it for a while,
then finally also removes it and consequentially
the object itself is then destroyed.
Would this be possible with TIP257-Objects?
Tom Conner
"Andreas Leitgeb" <a...@gamma.logic.tuwien.ac.at> wrote in message
news:slrneje8f...@gamma.logic.tuwien.ac.at...
Threads are probably used by few Tcl programmers. OOP, on the other hand,
is probably more commonly used, or at least desired, by a larger population
of Tcl programmers. So, to me, it makes more sense to get OO integrated and
correctly working in a single thread model, and then add multiple thread
support later. Getting side-tracked on esoteric scenarios is
counter-productive.
Eckhard Lehmann
Don Porter <d...@nist.gov> wrote:
> > Currently, when I create the [foo] command, it overwrites any existing
> > [foo] command in my interp. It's assumed I know what I'm doing.
> >
> > With magical multi-interp commands, I'd overwrite every [foo] command in
> > every interp? Including those I'm doing no business with at all?
No, you overwrite just the command in the interpreter where you are.
The others stay the same name. IMO, it would be quite silly to do that
with an object access command.
Andreas Leitgeb wrote:
> Being neither threads- nor itcl-expert, this leaves the
> question, whether it is (at least) possible to explicitly
> share an object between two interpreters.
Yes, yes, yes.... :-). I announced it some time ago. Look at
http://e-lehmann.de/index.php/tcltk/itcl-and-threads/
> Likely one can do so with interp alias, but this
> would mean one interpreter is still the master:
There are no master/slave relations needed. The access commands are
equally valued in each interpreter. The object structure stays alive as
long as there is at least one access command - no matter in which
interpreter this is.
This "disables" the object in one thread/interp on [delete], but makes
sure that it stays alive in other threads until they are finished with
it.
> Would this be possible with TIP257-Objects?
Probably yes, if TIP257-Objects work through access commands as well...
Depends on what DKF and the TCT think about it resp. what concerns they
have.
Eckhard
Eckhard Lehmann
Tom Conner wrote:
> Threads are probably used by few Tcl programmers. OOP, on the other hand,
> is probably more commonly used, or at least desired, by a larger population
> of Tcl programmers. So, to me, it makes more sense to get OO integrated and
> correctly working in a single thread model, and then add multiple thread
> support later. Getting side-tracked on esoteric scenarios is
> counter-productive.
Threads are not esotheric in GUI applications - and Tcl/Tk is mostly
used for that kind of applications. IMO, it is important to make long
running operations in a desktop application working so that the GUI
does not block. Sometimes the event loop is not sufficient for that.
By "long running operations" I mean for instance heavy computations,
network connections... etc.
While the TIP #257 OO is designed, it is a short step to think about
this and consider it. Later, when TIP #257 is deployed and running in
many production applications, it is hard to change the design. (I was
faced by such a design change for Itcl and it took me quite some time
to get it running in a way that does not break existing functionality).
Eckhard
Donal K. Fellows
> Threads are not esotheric in GUI applications - and Tcl/Tk is mostly
> used for that kind of applications. IMO, it is important to make long
> running operations in a desktop application working so that the GUI
> does not block. Sometimes the event loop is not sufficient for that.
> By "long running operations" I mean for instance heavy computations,
> network connections... etc.
So you farm those things off into worker threads. (Note that most
network connections do not need threads to work just fine in the
single-threaded event-driven model. It's only when the data throughput
is very high that you have a problem.) This has nothing to do with
objects though.
Note that even languages like Java recommend these days that GUIs are
effectively single threaded. Anything else just gets too weird.
> While the TIP #257 OO is designed, it is a short step to think about
> this and consider it. Later, when TIP #257 is deployed and running in
> many production applications, it is hard to change the design. (I was
> faced by such a design change for Itcl and it took me quite some time
> to get it running in a way that does not break existing functionality).
There is one model that counts: any object lives in a single
interpreter in a single thread. Other interpreters that need access to
it define their own objects that act as façades or proxies, forwarding
the method invokations to the real object. The advantage of this system
is that when it comes to building a more distributed model (e.g.,
across multiple processes or multiple machines) the main script-level
programming usage remains the same. Only the proxy object
implementations change.
This is good design BTW. Agrees with lots of nice software patterns.
:-)
Donal.
Sean Woods
The only way I have found to properly handle objects in a
multi-threaded environment, at least properly, is to have
one thread that is a dedicated "nirvana" where all of the
objects exist, and then pass commands to the objects
through RPC.
I've played around with this a lot in simulation software.
Trying to keep data syncronized between multiple copies
of an object is the path of pain.
That is not to say that you can't use objects in the
worker threads. The trick is to deligate all of the interface
functions to the worker threads, or restrict worker threads
to objects the flit in and out of existance.
Another trick, at least where real time interaction
between objects is not important, is to store your object
state in a database backend, and then call temporary
instances of an object into existance long enough
to carry out an action, and then dissolve away. I use
this system for my web engine. Generally a web page
is calling in a very small number of objects at a time,
and so long as everything gets done in a few milleseconds
the creation, cleanup, and destruction time is
imperceptible to the user.
Eckhard Lehmann
Donal K. Fellows wrote:
> Note that even languages like Java recommend these days that GUIs are
> effectively single threaded. Anything else just gets too weird.
I know. Usually I have objects that do the heavy lifting and are
separated from the GUI. GUI objects (Itk components or whatever) just
need access to them - e.g. a browser draws a tree object. This happens
in a single thread.
> There is one model that counts: any object lives in a single
> interpreter in a single thread. Other interpreters that need access to
> it define their own objects that act as façades or proxies, forwarding
> the method invokations to the real object.
Hmm, I see your point. Just to see whether I got it right: This means
for example, I have the main thread with my GUI stuff and a worker
thread with the objects that do heavy lifting. For each heavy lifting
object I have a delegating proxy object in the main thread through
which I send (async) method invocations to the lifter in the worker
thread. I vwait for the result and then I update the GUI also through
the delegating methods.
This means that for every heavy lifting object in the worker thread, a
proxy object in the main thread must exist. Some magic must provide
this. What happens if new objects are created in the worker thread? How
are the corresponding proxy objects in the main thread created and
where are they stored? Doesn't this require a kind of type information
(called "interfaces" in some languages) and how does that map to the
"everything is a string" concept? And what is the cost of creating
proxy objects - is it doable and performant enough in terms of memory
and processor speed for several 100 to 100000.. objects?
> The advantage of this system
> is that when it comes to building a more distributed model (e.g.,
> across multiple processes or multiple machines) the main script-level
> programming usage remains the same. Only the proxy object
> implementations change.
I see that this pattern makes a lot of sense for distributed
environments like CORBA/RPC, SOA... it also makes sense for inter
process communication on the same machine. But for threads, which
usually share the same memory anyway...?
Eckhard
Donal K. Fellows
> I see that this pattern makes a lot of sense for distributed
> environments like CORBA/RPC, SOA... it also makes sense for inter
> process communication on the same machine. But for threads, which
> usually share the same memory anyway...?
Sharing memory is at best merely an optimization. At worst, it is a
recipe for random smashes at unexpected times that vanish when you try
to hunt them down and yet hit with full force when you're doing that
critical demo to a key client. Tcl's apartment model of threads (i.e.
effectively lightweight processes) is a lot easier to debug and make
scale.
Donal.
Eckhard Lehmann
Donal K. Fellows wrote:
> Sharing memory is at best merely an optimization. At worst, it is a
> recipe for random smashes at unexpected times that vanish when you try
> to hunt them down and yet hit with full force when you're doing that
> critical demo to a key client.
I know very well.... That's why the whole multithreading thing should
only be used when it is necessary and makes sense. And then, careful
thoughts should be spent about synchronization. Most pitfalls can be
omitted by thinking about the question "what can happen when this runs
in parallel and where could it crash?".
For Itcl, I created the [synchronize] command, that locks the whole
object for critical code fragments (I think this was copied from Java
;-).
> Tcl's apartment model of threads (i.e.
> effectively lightweight processes) is a lot easier to debug and make
> scale.
That's right. But the advantages of shared memory are left out.
[tsv::get]/[tsv::set] make deep copies of variables, lists, keyed lists
and so on. That's fine for simple variables, but objects are often too
complex to be deep copied (nested objects and variables, circular
references, etc...).
The only options for objects are either to share the memory (as I do
for Itcl), or to use the proxy pattern as you described.
Eckhard
Michael Schlenker
I you have 100000 heavy lifiting objects you better run on a cluster
machine and if you do your limited by the network latency more than by
some dispatch or proxying overhead...
The hardest hit will be the cost to serialize large data structures,
because it is a bit tricky to pass internal representations of Tcl_Objs*
between different Interpreters in different threads.
>> The advantage of this system
>> is that when it comes to building a more distributed model (e.g.,
>> across multiple processes or multiple machines) the main script-level
>> programming usage remains the same. Only the proxy object
>> implementations change.
>
> I see that this pattern makes a lot of sense for distributed
> environments like CORBA/RPC, SOA... it also makes sense for inter
> process communication on the same machine. But for threads, which
> usually share the same memory anyway...?
>
Look up the Tcl thread model..., Tcl threads do _not_ have the shared
state as default, like threads in most languages, instead it uses a
message passing based shared nothing style...
Michael
Eckhard Lehmann
Michael Schlenker wrote:
> Look up the Tcl thread model..., Tcl threads do _not_ have the shared
> state as default, like threads in most languages, instead it uses a
> message passing based shared nothing style...
Trust me, I know the Tcl thread model very well ;-).
I also know where the shared memory is in this model - and believe me,
it is there. No wonder, since Tcl uses system threads and they *do*
have shared memory by nature and by definition.
The different interps encapsulate the data for you as Tcl developer,
but they are created in the shared memory as well as everything else.
If you don't believe me, check out Tloona (www.tloona.tk). It makes use
of thread shared Itcl objects. And in fact, there can be many of them
during a program run.
Eckhard
Donal K. Fellows
> 2 questions:
> - How are threads handled in TIP 257 and in your implementation? Is it
> (planned to be) possible to share objects between threads?
I've no plan to do so, but since #257 just provides a way of creating
methods, it should be possible to back the objects onto some shared
variable (using the Thread package?) and send messages back and forth so
that when one view-object goes away, so do the others. (Assuming that's
what is wanted by a thread-shared object, of course.)
> - Is Itk possible as well?
Darn well should be! If it isn't, I want to know! :-)
Donal.
Stéphane A.
> [...], it should be possible to back the objects onto some shared
> variable (using the Thread package?) and send messages back and forth so
> that when one view-object goes away, so do the others. (Assuming that's
> what is wanted by a thread-shared object, of course.)
Couldn't we create a new command for Incr Tcl that makes
(optionally would be fine) use of the Thread extension to share data
with other interpreters.
Such as :
class Foo {
private shared variable myvar ""
...
}
The [shared] qualifier should force ITcl
to handle this perticuliar variable somehow
special.
1) In each thread you might need the
shared variable, call :
new Foo $id <args>
The name '$id' should be the same across
multiple threads, but still created on demand.
2) Each read access to myvar should call:
tsv::set Foo::$id myvar
While much write access to myvar should call
the matching {set incr append lset lappend}
whenever possible.
Example :
{incr myvar} in a method is changed into this:
tsv::incr Foo::$id myvar
3) Common variables (static?) may also be shared
across multiple threads, but in the tsv::set calls
we should replace "Foo::$id" by "Foo::class".
tsv::set Foo::class mycommonvar ?value?
=========================
This approach would not cost much, but
I see one major drawback, which is solved by
shared *objects* : the initialization of these
shared variables.
In constructors, great care should be done
on how shared variables are set.
Indeed we are not like in Java, but with shared
data between two objects, instance-shared
variables instead of class-shared variables.
I must admit it is not a very good idea, but
perhaps it may help you to see other
points of view. :-)
Cheers,
Stephane
Donal K. Fellows
> This approach would not cost much, but
> I see one major drawback, which is solved by
> shared *objects* : the initialization of these
> shared variables.
I'd actually rather keep the data in a sqlite database on disk. Then
initialization becomes more of a non-issue since it is automatically
persistent. :-)
But I'm not going to mandate that other people do things this way.
Donal.
Eckhard Lehmann
Donal K. Fellows wrote:
> I'd actually rather keep the data in a sqlite database on disk. Then
> initialization becomes more of a non-issue since it is automatically
> persistent. :-)
Uhh, you're tough :-)!
Eckhard
Neil Madden
> Stéphane A. wrote:
>
>> This approach would not cost much, but
>> I see one major drawback, which is solved by
>> shared *objects* : the initialization of these
>> shared variables.
>
>
> I'd actually rather keep the data in a sqlite database on disk. Then
> initialization becomes more of a non-issue since it is automatically
> persistent. :-)
You also get proper ACID transactions that work over multiple processes
as well as multiple threads. Message-passing components backed up with a
persistent ACID database seems like the best way to do concurrency. Any
general explicit locking scheme tends to evolve into a poor
implementation of transactions eventually anyway (the DB equivalent of
Greenspun's tenth rule of programming).
-- Neil
Eckhard Lehmann
Donal K. Fellows wrote:
> I've no plan to do so, but since #257 just provides a way of creating
> methods, it should be possible to back the objects onto some shared
> variable (using the Thread package?) and send messages back and forth so
> that when one view-object goes away, so do the others. (Assuming that's
> what is wanted by a thread-shared object, of course.)
Generally I am in favour of implemting Itcl in either TIP #257 or the
new TIP #279 as GN has done. It would mean more compliance with the Tcl
core and less maintaining work for the current C based Itcl.
I'll jump on the train of new Tcl objects as well, when it is possible
to have Itcl interface to them ;-).
I had a new new idea about thread sharing this morning...
If objects are shared among threads, it is possible to access them
concurrent from any thread (with least memory consumption). Access to
the instance variables can be synchronised with recursive mutex
constructs.
However, it is not compliant with Tcl's idea of one interpreter per
thread. Currently, the interpreter ("interp") is the main structure,
where everything is angeled around.
But how about this:
- have TIP #257 objects the quasi main constructs of Tcl
- have an TIP #257 object "interp", which is like every other object,
with a method [eval] for interpreting Tcl code. Interpreter objects are
of type Interp, a class named like this is available.
At Tcl startup, there is one central "interp" object, which evaluates
everything. The same for every new thread. The Tcl developer can
construct more interpreter objects as he needs, and he can also create
special interpreters by deriving from the Interp class - e.g. to
achieve aliases, a special [eval] method or whatnot etc..
For thread sharing: There is a flag (like -ts) to make objects thread
shared, but interpreter objects can not be thread shared.
Quite visionary thoughts for a saturday morning... :-)
Eckhard
Jeff Hobbs
> However, it is not compliant with Tcl's idea of one interpreter per
> thread. Currently, the interpreter ("interp") is the main structure,
> where everything is angeled around.
>
> But how about this:
> - have TIP #257 objects the quasi main constructs of Tcl
> - have an TIP #257 object "interp", which is like every other object,
> with a method [eval] for interpreting Tcl code. Interpreter objects are
> of type Interp, a class named like this is available.
> At Tcl startup, there is one central "interp" object, which evaluates
> everything. The same for every new thread. The Tcl developer can
> construct more interpreter objects as he needs, and he can also create
> special interpreters by deriving from the Interp class - e.g. to
> achieve aliases, a special [eval] method or whatnot etc..
You could layer what you want on top of the existing code (as well as
proposed solutions). I believe I have seen an itcl version of what you
are looking for already - it also supported transparent network objects.
--
Jeff Hobbs, The Tcl Guy, http://www.activestate.com/