daniellansun commented on PR #2987:
URL: https://github.com/apache/groovy/pull/2987#issuecomment-6367956749
@paulk-asert Thank you. The local runs are reassuring, and the lost-value
race is fixed.
## Cancel that loses the commit
`relay` now breaks only when `cancel()` actually wins:
```java
if (self.isStopping() && !pending.isDone() && pending.cancel()) {
break;
}
```
If a sender commits between `isDone()` and `cancel()`, `cancel()` returns
false and the receive falls through to `await`, so the value is forwarded. The
next iteration still stops through `isStopping() && getBufferedSize() == 0`. A
deterministic stand-in covers that lost cancel: `isDone()` stays false and
`cancel()` completes the value but returns false.
## Buffered values on the other input
Left as specified. While the other input's buffer stays non-empty, `merge`
keeps forwarding, so a producer that refills the buffer can delay the failure
close until a gap appears. The Javadoc and the user guide say so.
## `produce`
`AsyncChannel.produce` and `produce(capacity)` run the body on the async
executor and close the channel when it finishes. `Producer.send` waits until
the channel accepts the value, including a rendezvous. A normal return closes
the channel normally. A thrown failure is passed to `close(cause)`, after the
values already accepted. A `ChannelClosedException` from `send` after the
consumer has already closed the channel is not recorded as a new failure.
`close(Throwable)` stays the primitive underneath.
```groovy
def channel = AsyncChannel.produce(2) {
it.send(1)
it.send(4)
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
