Am 26.05.2005 um 00:46 schrieb Jeff Hobbs:
Complex, yes, but still possible.
Well... see:
* Limitation: For C-based 'commands' with a non-NULL client data
* we do not know how to handle this. For the moment we simply
* copy the pointer. In the future commands may need a duplication
* method which is able to handle their client data.
I remember now, this was *one* of the points where I threw the towel.
We'd need some extension to the current command handling to allow
the clientData dups...
Apart from that, I see that the whole clone-process is doing
what it is expected to, but somehow I have mixed feeling about
the general usefulness of that.
For example, when you load some extension in one thread/interp, this
can have many side-effects which are not "visible" in that
interp only. So, without actually loading the extension again
in the other thread, you might miss some pieces. The extension can
maintain per-thread private structures which are not part of the
interp and thus not "cloned". So, in order to cover this, one must
also re-load all extensions. I cannot anticipate what side-effects
this could create in conjuction with C-level namespace copies done
by the Tcl_CloneInterp...
This interp-cloning looks very appealing on the first
glance but when you dig deeper, things start to complicate.
Also, although all in Tcl_CloneInterp is done in C, I'm afraid
that it could still take considerable time to copy 1000 or so commands
plus variables plus reload extensions. This might bless you with a
10's of milliseconds speed penalty which I do not believe people are
willing to accept. By introducing *whatever* kind of garbage-collection
or interp-cloning, there will be (perhaps significant) speed issues
introduced and everybody should be perfectly aware of that.
What also comes to mind is: create a slave interp, fill it with
aliases to master interp commands, run the request in the slave
and then trash the slave entirely. One would eventually need to
pay attention programatically *never* to change important state
data in the master but this would be out of the scope of the
implementation. I never actually tought deeper about that but
it is worth considering it as an option. Of curse, one would then
need something similar to Tcl_CloneInterp, but this is far more
simpler to do and would have no MT-related side-effects.
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
