[Tcl-bugs] [ tcl-Bugs-2905784 ] Sync [after] works too hard

[SourceForge.net <no...@so...>]

Bugs item #2905784, was opened at 2009-11-30 01:16
Message generated for change (Tracker Item Submitted) made by ferrieux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2905784&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 03. Timer Events
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Alexandre Ferrieux (ferrieux)
Assigned to: Kevin B KENNY (kennykb)
Summary: Sync [after] works too hard

Initial Comment:
Synchronous [after] makes many calls to the underlying OS's getttimeofday() or equivalent.
This is due to an ill-defined responsibility boundary between AfterDelay() and Tcl_Sleep().
Indeed, Tcl_Sleep() already has the logic to repeatedly check the current time and wait, not trusting the OS's time, and also taking car of virtual time.
However, AfterDelay repeats this logic one level up, calling Tcl_Sleep in a loop until endTime is reached.

The existence of the loop in itself has good reasons, namely respecting a reasonable granularity for limits or Async stuff.
But in the degenerate, but important, case of "small" delays below those limits, a very simple optimization (patch attached) lets AfterDelay call Tcl_Sleep exactly once, essentially "trusting" it on the accuracy of the resulting wait. Additionally, one trivial move of the Tcl_GetTime in the loop removes one unwanted extra gettimeofday().

The bottom line: this patch makes a small [after] generate only 3 gettimeofday()s: one on entry, to compute the endTime, and two inside Tcl_Sleep. Squeezing one more out would need a change in the Tcl_Sleep() API; I'm not attempting that.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2905784&group_id=10894