Re: after ids
- From: George Peter Staplin <georgepsSPAMMENOT@xxxxxxxxxxxx>
- Date: Sat, 12 Apr 2008 22:43:38 +0000 (UTC)
George Peter Staplin wrote:
Alexandre Ferrieux wrote:
On Apr 12, 5:31 pm, George Peter Staplin
<georgepsSPAMME...@xxxxxxxxxxxx> wrote:
Oh, sorry, it was only due to my busy morning and distractions that I
neglected to answer. There is no feature request for the tclTimer.c
ideas yet. Feel free to make one based on my post, and any of your
ideas relating to that. Also, pointing out that another person agreed
it's a problem in some cases would help.
I will do this with pleasure, but I would like to exchange a bit more
with you before.
I confirm my interest in seeing turned from linear to constant time
whatever lends itself to it in the core.
In order to do this, one solution is your approach, namely a more
elaborate data structure than the simple linked list and ever-
incremented ID. I've done exactly this in several of my own projects.
Now in the context of Tcl, there's an alternative: define a Tcl_Type
for after ids. This is currently done for procnames, variable names,
indexes, and even more recently for channels -- why not for afters ?
Of course, it won't work when the after id shimmers out. But letting
this happen requires a seriously contorted setup (like hiding after
ids in strings instead of just storing them in the usual containers).
I have no string opinion yet, I'd just like to know your analysis.
A Tcl_ObjType might be beneficial for Tcl_AfterObjCmd. Basically
instead of:
Tcl_SetObjResult(interp, Tcl_ObjPrintf("after#%d", afterPtr->id));
We would return a Tcl_Obj with a Tcl_ObjType that is just for use in
tclTimer.c. Normally this Tcl_Obj probably won't shimmer, and thus
[after canel] and [after info] would be faster, because the
objPtr->internalRep would have an integer value that we use as an offset
with the TimerHandler **table; If the string did shimmer we can
reinterpret the string rep, and convert it back to the Tcl_ObjType.
If say we used a representation like: after#123 (like the current
implementation): we would do something like:
int
GetTimerFromObj(Tcl_Obj *objPtr, long *offsetPtr) {
const char *prefix = "after#"
char *objStr;
int objStrLen;
size_t len = strlen(prefix);
if (objPtr->typePtr == &afterType) {
*offsetPtr = objPtr->internalRep->longValue;
return TCL_OK;
}
objStr = Tcl_GetString(objPtr, &objStrLen);
if (!strncmp(prefix, objStr, len) && objStrLen > len) {
long offset;
/* Tcl's strtol-like code using objStr + len and objStrLen - len */
/* free the internal rep */
objPtr->typePtr = &afterType;
objPtr->internalRep->longValue = offset;
*offset = offset;
}
Tcl_SetResult(interp, "inavlid id", TCL_STATIC);
return TCL_ERROR;
}
The table is allocated using something like:
table = (void *)Tcl_Alloc(sizeof(*table) * numTimers);
Then when we want to acccess a TimerHandler struct for after id or after
cancel:
struct TimerTable *t = GetTimerTableSomehow();
long offset;
if (GetTimerFromObj(obj, &offset) != TCL_OK) {
return TCL_ERROR;
}
if (offset >= 0 && offset < t->allocated && t->table[offset]) {
TimerHandler *timer = t->table[offset];
} else {
Tcl_SetResult(interp, "invalid id", TCL_STATIC);
return TCL_ERROR;
}
/* Remove this link from the double-linked list. */
if (timer->prevPtr) {
timer->prevPtr->next = timer->nextPtr;
}
if (timer->nextPtr) {
timer->nextPtr->prevPtr = timer->prevPtr;
}
t->table[timer->slot] = NULL;
----
Now say we have just run a timer, to remove it is as simple as:
t->table[timer->slot] = NULL;
+ Delink the sorted double-linked list :)
Whew, that was long. Anyway, that's my basic idea.
In hindsight it makes more sense for GetTimerFromObj to take a
Tcl_Interp * and set the result when it's an invalid object, followed by
a return of TCL_ERROR. I'll have to check on the interalRep
freeing/replacement code that's required.
The rest should be fairly simple, after a lot of review, and testing.
Feel free to run with the idea. I may not have the time and motivation
for a while. I'd be happy to review any changes though.
George
.
- Follow-Ups:
- Re: after ids
- From: Alexandre Ferrieux
- Re: after ids
- References:
- after ids
- From: vitick
- Re: after ids
- From: George Peter Staplin
- Re: after ids
- From: Bruce Hartweg
- Re: after ids
- From: Darren New
- Re: after ids
- From: George Peter Staplin
- Re: after ids
- From: Alexandre Ferrieux
- Re: after ids
- From: George Peter Staplin
- Re: after ids
- From: Alexandre Ferrieux
- Re: after ids
- From: George Peter Staplin
- after ids
- Prev by Date: Re: after ids
- Next by Date: Re: ISO an algorithm
- Previous by thread: Re: after ids
- Next by thread: Re: after ids
- Index(es):
Relevant Pages
|