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 |