Am 22.02.2017 11:24 schrieb "Daniel Martin" <[email protected]>:
On 21 February 2017 at 17:48, walter harms <[email protected]> wrote: > Am 20.02.2017 10:55, schrieb Daniel Martin: >> What happens is: >> - ServertimeBlockHandler() forwards a _big_ unsigned timeout to >> AdjustWaitForDelay() >> - AdjustWaitForDelay() takes this _big_ unsigned as int and it becomes >> a negative value >> - the negative value ends up as timeout in ospoll_wait() as parameter >> to epoll_wait() >>> epoll_wait() blocks due to the negative timeout >> >> XSyncValueSubtract() doesn't handle unsigned wraps. That's why we get >> a big unsigned from ServertimeBlockHandler(). Just imagine two >> XSyncValues: >> a = {.hi=1, .lo=1} and b = {.hi=0, lo=.2}. >> The result of XSyncValueSubtract(a - b) is >> presult = {.hi=0, .lo=4294967295}, >> where I would expect >> presult = {.hi=0, .lo=9}. >> >> If .lo=4294967295 is wrong and .lo=9 is what we want, could anyone >> provide a fix, please? I'm to dumb for the (binary?) arithmetic atm. >> (And if it is wrong, did I just uncovered an ancient bug?) >> > > XSyncValueSubtract is doing as expected, > XSyncValue is the simulation of 64bitvalues on 32bit. > see this in hex: > 100000001 > -000000002 > 0FFFFFFFF = 4294967295 in .lo If XSyncValueSubtract is correct as is, then I would say, that it is not what we want in ServertimeBlockHandler(). At that point we handle XSyncValues like a struct timeval, though .lo not being in usec, but ms. So, every .lo < 0 or > 999 is wrong. That's wrong. Ignore this.
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
