timespec translation fails for times before 1970

[Philipp Huber <phu@…>]

I had a target system that had always a failed assertion with a call to condition_variable::timed_wait();

I found out, that pthread_cond_timedwait does not accept a timespec argument that has negative tv_nsec.

Therefore I suggest the following patch, which works for me.

=================================================================== --- /boost/boost_1_43_0/boost/thread/pthread/timespec.hpp (revision 1769) +++ /boost/boost_1_43_0/boost/thread/pthread/timespec.hpp (working copy) @@ -26,6 +26,13 @@

timeout.tv_sec=time_since_epoch.total_seconds(); timeout.tv_nsec=(long)(time_since_epoch.fractional_seconds()*(1000000000l/time_since_epoch.ticks_per_second()));

+ + if(timeout.tv_nsec < 0L) + { + timeout.tv_sec -= 1L; + timeout.tv_nsec += 1000000000L; + } +

return timeout;

}

}

[Philipp Huber <phu@…>]

by the way, the system time was 1919 and so timeout.tv_sec as well as timeout.tv_nsec became negative. tv_sec are accepted negative but not tv_nsec.

[anonymous]

1000000000L is a magic number. I suggest that it be replaced using a const long.

[viboes]

I would say that in this case an exception must be thrown.

[viboes]

I would like to understand how the seconds are positive and the nanoseconds are negative. Could you post an example?

[phu@…]

Hi viboes

Well, 16 month is quite a while ago... We do use boost intensively but have fixed already 3 bugs in different parts of boost, all sent to this bug tracker tool but with little or no response. So we keep on fixing every new release...

We used boost for embedded linux on a hardware with broken realtime clock. So the system time was often randomly startet and in this case it was 1919.

The timeout resulted from a calculation of some time value minus another time value. let's say, we scheduled a timer to a specific absolute time. The scheduler thread inspects this time value, compares it with the current posix time and calculates how long it needs to sleep until the timer will be signaled. If the scheduler is busy, it can happen that the sleep timeout, which is basically the subtraction of two times, becomes negative. But it only happend with the low year numbers of 1919. At least, that is what I think caused the timeout to become negative. But I can't tell you for sure. After 16 Month.

I understand that you would like to fix the cause of the negative timeout but as long as the timeout type allows negative values, you can not avoid a call with negative values in general anyway.

What I can tell you for sure is, that the bugfix, which I suggested works well for us. Whether or not it is fixing the real cause of the bug.

cheers phu

[viboes]

Replying to phu@…:

Hi viboes

Well, 16 month is quite a while ago...

It is always better late than never ;-)

We do use boost intensively but have fixed already 3 bugs in different parts of boost, all sent to this bug tracker tool but with little or no response. So we keep on fixing every new release...

I'm trying to change this.

We used boost for embedded linux on a hardware with broken realtime clock. So the system time was often randomly startet and in this case it was 1919.

The timeout resulted from a calculation of some time value minus another time value. let's say, we scheduled a timer to a specific absolute time. The scheduler thread inspects this time value, compares it with the current posix time and calculates how long it needs to sleep until the timer will be signaled. If the scheduler is busy, it can happen that the sleep timeout, which is basically the subtraction of two times, becomes negative. But it only happend with the low year numbers of 1919. At least, that is what I think caused the timeout to become negative. But I can't tell you for sure. After 16 Month.

I understand that you would like to fix the cause of the negative timeout but as long as the timeout type allows negative values, you can not avoid a call with negative values in general anyway.

What I can tell you for sure is, that the bugfix, which I suggested works well for us. Whether or not it is fixing the real cause of the bug.

cheers phu

Thanks for the explanation. IIUC,and if you where using directly the underlying platform you will need to make sure that the time given satisfy the interface constraints and when you did a difference you will ensure that the seconds and nanoseconds will be positive, isn't it?

I think that you will do the same when using Boost.Chrono. The best I can do is to add an assertion so that the modification doesn't add code on release mode.

Let me know what do you think of this resolution?

Best, Vicente

[phu@…]

Hi Vicente

Thanks for taking up the bug. Right you are, better late than never. I stripped the answer a bit to get to the point:

Replying to viboes:

Replying to phu@…:

Thanks for the explanation. IIUC,and if you where using directly the underlying platform you will need to make sure that the time given satisfy the interface constraints ...

Well, we have a correct linux system time. Even if it shows the year 1919, I think it perfectly satisfy the interface constraints. Well, I might be a bit naive on that point.

... and when you did a difference you will ensure that the seconds and nanoseconds will be positive, isn't it?

We subtract two ptime values. I expect the value to be usable for further operations. I would not check every subtraction for its correct value (whether its components are positive or not), that is what I expect of the operation to do.

I think that you will do the same when using Boost.Chrono. The best I can do is to add an assertion so that the modification doesn't add code on release mode.

Sorry, but I might be misunderstanding this point. If we end up with an assertion instead of a working program flow, I'm not exactly happy with the solution. Then I prefer you do nothing at all and we continue the way we did so far.

Let me know what do you think of this resolution?

Best, Vicente

Thanks for looking into it anyway :-) Cheers Philipp

[viboes]

Replying to phu@…:

Replying to viboes:

Replying to phu@…:

Thanks for the explanation. IIUC,and if you where using directly the underlying platform you will need to make sure that the time given satisfy the interface constraints ...

Well, we have a correct linux system time. Even if it shows the year 1919, I think it perfectly satisfy the interface constraints. Well, I might be a bit naive on that point.

... and when you did a difference you will ensure that the seconds and nanoseconds will be positive, isn't it?

We subtract two ptime values. I expect the value to be usable for further operations. I would not check every subtraction for its correct value (whether its components are positive or not), that is what I expect of the operation to do.

What do you use to make this difference? Boost.Date?

I think that you will do the same when using Boost.Chrono. The best I can do is to add an assertion so that the modification doesn't add code on release mode.

Sorry, but I might be misunderstanding this point. If we end up with an assertion instead of a working program flow, I'm not exactly happy with the solution. Then I prefer you do nothing at all and we continue the way we did so far.

The question is if the ptime given as parameter must be a valid one, that is, if it is a precondition. IMO, this is the spirit of a lot of standard functions, so that the implementation is not required to test the validity of the informations received in the parameters.

[viboes]

Moved to support request until resolution clarified

[viboes]

Closed. Please answer the questions and reopen it if you consider necessary.