On 2005.02.25, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
> All resources in this interpreter not handled by the programmer
> *or* by ns_cleanup will stay until this interp gets dumped. It will
> never get dumped if the connection thread never exits. And it will
> never exit if connsperthread == 0. Is this what we are talking about?
Yes. And, for performance reasons, you WANT to set connsperthread == 0,
which is the default.
> > No, but tDOM could provide a way of letting AOLserver clean up
> > tDOM-created objects. Currently, there is NO fail-proof way of doing
> > the cleanup, which is why I asked for a [tdom cleanup] where tDOM could
> > track what objects it's created and then clean them up when asked to.
>
> OK. This is clear. The [dom cleanup] kind of thing would be
> feasible and practical. No doubt about it. I will see with
> Rolf to get it in the CVS.
Great! I suggested this a while back and you can read Rolf's responses
in the thread. See if he's changed his mind since then.
http://groups.yahoo.com/group/tdom/message/922
| > Basically, what we need is a list to be maintained in what is
| > known as "connection-local storage" in AOLserver terminology of
| > all the proc's created by tDOM, so that at the end of the
| > connection, we can get a list of them all and then [rename] them
| > away or Tcl_DeleteCommand() from C. This implies that
| > everywhere these proc's are created, we would need to add them
| > to the list maintained in CLS (conn-local storage), and when the
| > proc delete traces execute, they would have to be removed. A
| > simple Tcl_HashTable should work just fine for this.
| >
| > I'm going to try and find some time to implement this and submit
| > a patch, but in the meantime -- do you have any objections to
| > this approach?
|
| I'm not convinced, so far. Mostly because, I don't see the
| problem, as described above. But feel free, to come up with a
| concrete application scenario, to convince me.
> > That's it. The suggestion is that by default tDOM should be creating
> > the commands in a sub-namespace of "tdom" to avoid it polluting the
> > caller's namespace. This would also make automated cleanup of
> > tDOM-created objects possible.
>
> Well, this is not difficult to make. The only thing is how to
> assure backward compatibility? I will discuss this with Rolf
> and we will see what we can do about it...
Backward-compatibility will be the tough one. appendFromScript could
evaluate the script within the sub-namespace, but then calling procs
that are not in that namespace may get messy. Or at least, ones in
their own namespaces outside the top-level :: namespace, at least --
whatever isn't in Tcl's normal search path for procs.
> So, basically, either [tdom cleanup] or tdom:: private namespace
> or both...
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
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.
