On Fri, 23 May 2025 06:14:37 GMT, Daniel Jeliński wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (upda
On Fri, 23 May 2025 06:14:37 GMT, Daniel Jeliński wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (upda
On Fri, 23 May 2025 06:11:47 GMT, Daniel Jeliński wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (upda
> We observed a case where the instants returned by `TimeSource.now()` were
> returned in non-monotonic order. The reason was that sometimes we were using
> a delay calculated with one `localSource` as an input to a different (updated
> on another thread) `localSource`. This was confirmed by put
On Thu, 22 May 2025 18:56:29 GMT, Daniel Jeliński wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (upda
On Thu, 22 May 2025 18:56:29 GMT, Daniel Jeliński wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (upda
> We observed a case where the instants returned by `TimeSource.now()` were
> returned in non-monotonic order. The reason was that sometimes we were using
> a delay calculated with one `localSource` as an input to a different (updated
> on another thread) `localSource`. This was confirmed by put
On Thu, 22 May 2025 10:52:44 GMT, Daniel Fuchs wrote:
>> Hello Daniel, with this proposed change, is there any reason to have the
>> `localSource` field in this `TimeSource` anymore?
>
> Yes. It avoids the volatile read on nanoSource.
It could serve as a safety net. But I can also revert this a
On Thu, 22 May 2025 10:35:57 GMT, Jaikiran Pai wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/common/TimeSource.java
>> line 97:
>>
>>> 95: // use localSource if possible to avoid a volatile read
>>> 96: if (source.isInWindow(delay)) {
>>> 97: return
On Thu, 22 May 2025 09:59:58 GMT, Daniel Fuchs wrote:
>> We observed a case where the instants returned by `TimeSource.now()` were
>> returned in non-monotonic order. The reason was that sometimes we were using
>> a delay calculated with one `localSource` as an input to a different
>> (updated
On Thu, 22 May 2025 09:53:26 GMT, Daniel Jeliński wrote:
> We observed a case where the instants returned by `TimeSource.now()` were
> returned in non-monotonic order. The reason was that sometimes we were using
> a delay calculated with one `localSource` as an input to a different (updated
>
We observed a case where the instants returned by `TimeSource.now()` were
returned in non-monotonic order. The reason was that sometimes we were using a
delay calculated with one `localSource` as an input to a different (updated on
another thread) `localSource`. This was confirmed by putting `as
12 matches
Mail list logo
