Tcl Source Code

View Ticket
Login
Ticket UUID: 2010350
Title: Extend "after info" capabilities
Type: RFE Version: None
Submitter: o_lenormand Created on: 2008-07-04 06:58:30
Subsystem: 03. Timer Events Assigned To: kennykb
Priority: 5 Medium Severity:
Status: Open Last Modified: 2010-11-24 00:08:56
Resolution: None Closed By:
    Closed on:
Description:
Purpose: make a richer version of "after info"

Informations returned by "after info" is accurate but not as rich as it could.
When dealing with a lot of concurrent timers (I'm building a tcl-only scheduler), one quickly needs more detailed informations.

Today "after" lacks a command that returns the time-ordered timers in the queue, and the current values of their associated timers.

I'm thinking of two new commands, such as:

 - after next: returns the timer value of the next timer to be activated.
Example:
% after 10000 {puts hi!}
after#0
% after next
4581

 - after xinfo : it's a rich version of "after info", taht deals with all the existing timers.
It should return a list like:
{<event_i> <command_i> <timer_i> [<event_j> <command_j> <timer_j> ...]}

Example:
% after 10000 {puts hi!}
after#0
% after 30000 {puts "hi again!"}
after#1
% after xinfo
after#0 {puts hi!} 2940 after#1 {puts "hi again!"} 21708

The list elements are chronogicaly sorted, the first the sooner (it seems that's not the way "after info" works).

Though "after next" is a sub-result of "after xinfo", it's a convenient way of getting straight this information.

Thoses two commands will give us the capability to handle complex and heavy Timer usages.
I'd love to see these two commands integrated in tcl'core :)

Thanks in advance, Olivier.
User Comments: ferrieux added on 2010-11-24 00:08:56:

File Deleted - 283610:

ferrieux added on 2010-11-24 00:08:42:

File Added - 394173: afterxinfo3.patch

ferrieux added on 2010-02-02 05:40:40:

File Added - 361247: afterxinfo4.patch

ferrieux added on 2008-07-04 14:09:05:

File Added - 283610: afterxinfo3.patch

Logged In: YES 
user_id=496139
Originator: NO

TIP to come.
Just attached a patch implementing [after next] and [after xinfo] commands.
It uses the already-sorted internal list of timer handlers instead of the LIFO used by [after info].
This means the filtering out of non-after handlers (like the hidden ones from buffered fileevents) is done in a slightly different way, by comparing timerHandle->proc with AfterProc (no AfterInfo nor assocPtr can be reached in the fileevent case, since the clientData is a ChannelData). Kevin please tell me if this is acceptable or not. 
File Added: afterxinfo3.patch

Attachments: