(Related to my previous shimmering email)
There are many Tcl_Obj types which cannot be constructed from a
string (such as channels and sockets). The convention is to use a
"handle" name for these. With a handle, you can look everything else
up in a hash table.
Handles are nice, but they don't clean up. Tcl's reference counts
will not help, even though they accurately track all uses of
Tcl_Obj's. I don't think it is intuitive to have to close a channel
when its handle (i.e. name) is no longer around, to give one
example. If automatic cleanup is a differentiator for scripting
languages such as Tcl, then "return [read [open myfile]]" ought to do
the right thing.
I was wondering if we could turn this problem around and include
objects safely inside Tcl_Obj's (without adding fields to Tcl_Obj).
I know it's been discussed a lot in the past.
It needs *one* change to Tcl: if the bytes ptr is *odd* when
releasing it, then do something special before actually doing the
There is *one* crucial assumption: ckalloc never returns an odd-
If these two conditions are met, then it is possible to accurately
track the loss of a string rep and call Tcl_ObjType-specific code.
First a caveat: this is not a solution for everything. You can *not*
set h [handlegeneratingproc]
set x <$h>
set h [string range $x 1 end-1]
and expect the associated object to survive.
So it has the same limitations as with the shimmering-of-large-
objects email. Once a handle is no more than a substring, it is
effectively gone (and will be cleaned up by what I'm proposing here).
The trick is to allocate a string rep with extra bytes (9, in this
example). That memory gets filled in as follows:
0..3: 4 bytes = destructor-fun-ptr
4..7: 4 bytes = ptr to extra data
8: 1 byte = 9, the number of extra bytes
9..N+7: N bytes = the string rep, i.e. handle name
N+8: 1 byte = terminating null byte
(sizes change on 64-bit cpu's but the trick remains the same)
Then, make Tcl_Obj's bytes field point to the string rep, i.e. ptr+9.
So bytes is odd. The byte just before the string says where the
allocated memory really starts. And the first item in that memory is
the function to call before ckfree-ing the entire memory area.
Payoff: object state which survives all clear cases of shimmering.
Feel free to shoot it down. I have no vested interest. I do think
this or something related is worth looking into. The inability to
release unused "objects" (fill in whatever you like for this term
here) is a major weakness in Tcl, IMO. It has probably prevented
tons of other ideas (such as procs/lambdas/closures as Tcl_Obj's)
from becoming feasible. Dunno, I may be wrong.