Comment 50 for bug 595555
Revision history for this message
|
|
#50 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
513534c
demo site
(Get the code!)
Created attachment 446373
Fig.38 illustration on Def.1 and Def.3 of +/- transition alarms
Chris,
Thanks for replying! Sure, you guys did the work on Xext/sync.c, so
you decide what to do. I am just saying that there is an easier way
(Comment #27) to fix the same issue (and the problematic definition of
negative transition) without jumping through hoops (ie. schedule a 1ms
timer when the counter falls on the threshold, which occurs quite
often). I am of the old school of "keep it simple and stupid."
For this bug, I saw 3 definitions of the transition counters; they
boil down to the following: (th=threshold, oldval=previous value of
counter, newval=new value of counter)
Def.1 (Before any of these fix)
+trans: triggers when oldval < th && th <= newval
-trans: triggers when newval <= th && th < oldval
Def.2 (from Chris, link in Comment #35)
+trans: triggers when oldval < th && th <= newval
-trans: triggers when newval < th && th < oldval
(Please correct me if I wrongly interpreted your definition; I got
this interpretation from your comment
The {Positive,
counter goes from strictly {below,above} the threshold.
and your other comment
* We've been called exactly on the idle time, but we have a
* NegativeTransition trigger which requires a transition from
* an idle time greater than this. Schedule a wakeup for the
* next millisecond so we won't miss a transition.
)
Def.3 (from Tim, Comment #27)
+trans: triggers when oldval < th && th <= newval
-trans: triggers when newval < th && th <= oldval
Def.1 can be interpreted as follows.
Assume th=60; let th' = th -/+ epsilon (eg. 0.1) = 59.9/60.1.
+trans: oldval < 59.9 && 59.9 < newval
-trans: oldval < 60.1 && 60.1 < newval
This view results in the the same behavior as Def.1. But in this view
it is obvious that, given the same th, +trans and -trans actually
occur on different thresholds (th -/+ epsilon, respectively). See
attached Fig.38 for illustration.
From this point of view, Def.3 is more consistent than Def.1: Def.3
uses the same threshold (th - epsilon) for both +/- transition alarms
(see Fig.38). It is also less surprising to the API users, as proven
by the usage of SYNC ext by g-ss and g-p-m (both use the same
threshold for +/- trans. alarms).
> The SYNC extension defines a negative transition as triggered from a
> counter strictly *above* the threshold to ≤ the threshold
If this is the case, why do you need to change anything? The current
implementation (before your change) correctly implemented this
definition. But could you point me to where this is defined? [1]
seems to be the standard about SYNC ext, but it leaves the exact
definition of +/- trans. to the implementation. [2] has concrete
definition, which is same as Def.1. But [2] is a Programmer's Guide,
not a doc defining SYNC ext.
> I think the changes in [Comment #27] ... are wrong.
Yup, it committed the crime of going against a Programmer's Guide,
which is carved in the stone. Reminded me of the guy who was in jail
for two years, because he failed to put a US. Federal-required label
on his UPS package.
Again, my thanks to you guys working on Xext/sync.c. What I described
was just a suggestion, and hopefully an easier way for the same job.
You don't have have to heed or follow.
[1] X Synchronization Extension Library, Version 3.0, X Consortium
Standard X Version 11, Release 6.4. Tim Glauert, Dave Carver, Jim
Gettys, David P. Wiggins; 1991.
http://
- no concrete definition of +/- transition.
[2] "X Synchronization Extension," X Window System Programmer's Guide
Chapter 9
"If the test-type is NegativeTransition, the trigger is initialize
to FALSE and it will become TRUE when the counter changes form a
value greater than the test value to a value less than or equal to
the test value."
http://