On Thu, 12 Jun 2025 09:54:57 GMT, kabutz wrote:
>>> About a month or so.
>>
>> Perfect, thanks @viktorklang-ora. I've marked the other issues as closed -
>> duplicates, and referenced this single umbrella PR.
>
>> Great work, @kabutz — this is now ready to integrate.
>
> What are the next step
On Thu, 12 Jun 2025 09:54:57 GMT, kabutz wrote:
>>> About a month or so.
>>
>> Perfect, thanks @viktorklang-ora. I've marked the other issues as closed -
>> duplicates, and referenced this single umbrella PR.
>
>> Great work, @kabutz — this is now ready to integrate.
>
> What are the next step
On Wed, 11 Jun 2025 19:44:20 GMT, kabutz wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does not beh
On Thu, 12 Jun 2025 09:54:57 GMT, kabutz wrote:
>>> About a month or so.
>>
>> Perfect, thanks @viktorklang-ora. I've marked the other issues as closed -
>> duplicates, and referenced this single umbrella PR.
>
>> Great work, @kabutz — this is now ready to integrate.
>
> What are the next step
On Tue, 13 May 2025 13:16:45 GMT, kabutz wrote:
>>> > @kabutz I think @AlanBateman might be able to have a look as well.
>>> > As for timing, it seems to me most reasonable if this PR (if it is to be
>>> > integrated) to go in _after_ JDK25 has been forked, to give enough time
>>> > for JDK26 e
On Wed, 11 Jun 2025 19:44:20 GMT, kabutz wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does not beh
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
On Wed, 11 Jun 2025 09:52:19 GMT, kabutz wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does not beh
On Wed, 11 Jun 2025 09:52:19 GMT, kabutz wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does not beh
On Wed, 11 Jun 2025 09:17:57 GMT, Viktor Klang wrote:
>> kabutz has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Removed sizes from LBD constructors - not necessary
>> - More optimizing volatile reads
>
> test/jdk/java/util/concurrent/
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
On Tue, 10 Jun 2025 16:03:47 GMT, kabutz wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does not beh
On Tue, 10 Jun 2025 10:13:20 GMT, Viktor Klang wrote:
>> kabutz has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Whitespace
>
> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
> line 225:
>
>> 223: ++co
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
On Mon, 9 Jun 2025 16:53:07 GMT, kabutz wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does not beha
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
On Thu, 8 May 2025 14:27:07 GMT, kabutz wrote:
>> test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java line 1958:
>>
>>> 1956: q.add(four);
>>> 1957: q.add(five);
>>> 1958: q.add(six);
>>
>> Out of curiosity, how does `it.remove()` work under these conditions?
On Mon, 9 Jun 2025 13:11:34 GMT, Viktor Klang wrote:
>> What would you like to do if the invariant fails inside linkFirst() and
>> linkLast()? Should we throw an AssertionError each time?
>
> No, I was more thinking keeping it as it was: (return true/false from
> linkFirst / linkLast depending
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave consistently with other concurrency
> components. If
On Mon, 9 Jun 2025 11:58:03 GMT, kabutz wrote:
>> @kabutz I'd think maintaining the invariants within linkFirst and linkLast
>> would be preferable (`count` must be re-read under the lock anyway)
>
> What would you like to do if the invariant fails inside linkFirst() and
> linkLast()? Should we
On Mon, 9 Jun 2025 09:20:31 GMT, Viktor Klang wrote:
>>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not
>>> enforcing the invariant. What's the benefit to changing linkFirst and
>>> linkLast to return void instead of keeping the original returning a boolean?
>>
>> I bas
On Mon, 9 Jun 2025 09:24:57 GMT, Viktor Klang wrote:
>>> We could likely check if there's any remaining capacity up front, and
>>> immediately return false?
>>
>> We could if you like. I wanted to make as few changes as possible, to not
>> introduce unexpected changes. This particular bug was
On Thu, 8 May 2025 13:53:31 GMT, kabutz wrote:
>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
>> line 860:
>>
>>> 858: // As historically specified in AbstractQueue#addAll
>>> 859: throw new IllegalArgumentException();
>>> 860:
>>
>> We co
On Thu, 8 May 2025 13:47:41 GMT, kabutz wrote:
>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
>> line 341:
>>
>>> 339: if (count >= capacity)
>>> 340: return false;
>>> 341: linkFirst(node);
>>
>> I'm a bit uneasy about incr
On Tue, 13 May 2025 13:16:45 GMT, kabutz wrote:
>>> > @kabutz I think @AlanBateman might be able to have a look as well.
>>> > As for timing, it seems to me most reasonable if this PR (if it is to be
>>> > integrated) to go in _after_ JDK25 has been forked, to give enough time
>>> > for JDK26 e
On Tue, 13 May 2025 12:44:38 GMT, Viktor Klang wrote:
> About a month or so.
Perfect, thanks @viktorklang-ora. I've marked the other issues as closed -
duplicates, and referenced this single umbrella PR.
-
PR Comment: https://git.openjdk.org/jdk/pull/24925#issuecomment-2876484773
On Wed, 7 May 2025 17:01:29 GMT, kabutz wrote:
> > @kabutz I think @AlanBateman might be able to have a look as well.
> > As for timing, it seems to me most reasonable if this PR (if it is to be
> > integrated) to go in _after_ JDK25 has been forked, to give enough time for
> > JDK26 early acce
On Fri, 9 May 2025 14:50:49 GMT, Viktor Klang wrote:
>>> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not
>>> enforcing the invariant. What's the benefit to changing linkFirst and
>>> linkLast to return void instead of keeping the original returning a boolean?
>>
>> I bas
On Thu, 8 May 2025 13:47:41 GMT, kabutz wrote:
>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
>> line 341:
>>
>>> 339: if (count >= capacity)
>>> 340: return false;
>>> 341: linkFirst(node);
>>
>> I'm a bit uneasy about incr
On Thu, 8 May 2025 14:28:18 GMT, kabutz wrote:
>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java
>> line 865:
>>
>>> 863: long n = 0;
>>> 864: for (E e : c) {
>>> 865: Objects.requireNonNull(e);
>>
>> This makes me wonder: Does it make sen
On Thu, 8 May 2025 08:59:59 GMT, Viktor Klang wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does no
On Thu, 8 May 2025 08:33:06 GMT, Viktor Klang wrote:
> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not
> enforcing the invariant. What's the benefit to changing linkFirst and
> linkLast to return void instead of keeping the original returning a boolean?
I based the appro
On Thu, 8 May 2025 08:41:52 GMT, Viktor Klang wrote:
> We could likely check if there's any remaining capacity up front, and
> immediately return false?
We could if you like. I wanted to make as few changes as possible, to not
introduce unexpected changes. This particular bug was to stop a siz
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Wed, 7 May 2025 10:43:55 GMT, kabutz wrote:
>> @kabutz Thanks for opening this PR—just confirming that it's on my to-review
>> queue.
>
> @viktorklang-ora any idea whom else we can ask to approve this PR?
> @kabutz I think @AlanBateman might be able to have a look as well.
>
> As for timing
On Wed, 7 May 2025 10:43:55 GMT, kabutz wrote:
>> @kabutz Thanks for opening this PR—just confirming that it's on my to-review
>> queue.
>
> @viktorklang-ora any idea whom else we can ask to approve this PR?
@kabutz I think @AlanBateman might be able to have a look as well.
As for timing, it s
On Mon, 28 Apr 2025 19:48:40 GMT, Viktor Klang wrote:
>> @viktorklang-ora @DougLea @AlanBateman
>
> @kabutz Thanks for opening this PR—just confirming that it's on my to-review
> queue.
@viktorklang-ora any idea whom else we can ask to approve this PR?
-
PR Comment: https://git.op
On Fri, 2 May 2025 13:19:13 GMT, Doug Lea wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does not be
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Mon, 28 Apr 2025 15:33:50 GMT, kabutz wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does not beh
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
We logged several bugs on the LinkedBlockingDeque. This aggregates them into a
single bug report and PR.
1. LinkedBlockingDeque does not immediately throw InterruptedException in
put/take
The LinkedBlockingDeque does not behave consistently with other concurrency
components. If we call putFirs
49 matches
Mail list logo
