Overflow in toAbsoluteTime

[leonpollak]

Hello, dear developers.
I finally managed to compile OUTPOST and run my application under ARM and here start the problems...:-)
I am trying to wait for my queue for infinite duration.
What happens is that arriving to the function toAbsoluteTime with this infinity() duration, first is:
uint64_t nanoseconds = duration.microseconds() * 1000;
As the microseconds is the maximumValue number (9223372036854775807), nanoseconds becomes even more: 18,446,744,073,709,550,616 - don't know why, but this is the result gdb gives.
Thus the last operator:
absoluteTime.tv_sec += static_cast(nanoseconds / 1000000000);
tries to add more than 18billions which makes the result effectively negative(!).
Passing negative time to pthread_cond_timedwait() end it immediately, which obviously is not the desired result...:-)

I shall be very thankful for any comments

[fabian-dlr]

You are absolutely right, I'll look into this.

[leonpollak]

OK, I understand now where the problem is: my compilation is for 32-bit machine.
In this case, the "timespec" structure definition in Linux looks different in the /usr/include - its elements are also 32-bits long. Thus, the operator
absoluteTime.tv_sec += static_cast(nanoseconds / 1000000000);
results an error value.
Now, what I should suggest is - why do we need to make all these complicated 64-bit calculations in the case when the "forever" timeout is required? So, I made the following change to toAbsoluteTime function at the beginning:
if (duration == time::Duration::infinity()) {
absoluteTime.tv_sec = sizeof(timespec)==16?0x7FFFFFFFFFFFFFFF:0x7FFFFFFF;
return absoluteTime; }
This looks a bit clumsy, but does its work...:-)

[leonpollak]

Sorry for been too fast...:-)
The following must(!) be added:
absoluteTime.tv_nsec = 0;

[fabian-dlr]

In my opinion this is the wrong place to solve this. I've updated our internal mirror with a fix which handles this problem at places where waiting actually happens (queue, mutex and semaphores). This solves this problem even when getting closer to the year 2038 (where all systems still using a 32 bit type for the seconds will overflow).

As soon as the changes have been reviewed I'll push it to this repository as well (which will be in the next few days).

[fabian-dlr]

Hi @leonpollak, the master branch have been updated regarding the POSIX time handling. It would be great if you could check if this fixes your problem.

[leonpollak]

Hi, Fabian.
Yes, the last hardly reworked(!!) code has no this issue - my tests passed smoothly.
Thank you very much!!!!!

[leonpollak]

Sorry for late reaction - a lot of other things to do...:-)
The new version has a problem:
the new toAbsoluteTime function uses monotonic clock to define the start time point, while functions like pthread_cond_timedwait() use system clock.
Thus all calls to pthread_cond_timedwait() results in immediate timeout.

[fabian-dlr]

Yeah, that is an oversight on my part. I've looked through the documentation, as it turns out it is not possible to use the monotonic clock for everything. For pthread_cond_timedwait there is a possibility on Linux, but for pthread_mutex_timedlock nothing similar exisits (in a portable way). That is annoying.

I've changed those clocks back to CLOCK_REALTIME which should restore their behavior.