pnowojski commented on a change in pull request #18173:
URL: https://github.com/apache/flink/pull/18173#discussion_r773910917
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/io/network/buffer/NetworkBufferPool.java
##########
@@ -158,7 +159,8 @@ public MemorySegment requestMemorySegment() {
public List<MemorySegment> requestMemorySegmentsBlocking(int
numberOfSegmentsToRequest)
throws IOException {
- return internalRequestMemorySegments(numberOfSegmentsToRequest);
+ return internalRequestMemorySegments(
+ numberOfSegmentsToRequest,
this::internalRecycleMemorySegments);
Review comment:
Why is it safe to acquire the lock in `requestMemorySegmentsBlocking`
but no in `requestMemorySegments`?
As a side note, the names of those methods seems to be misleading, as both
of them are blocking, and they only seem to differ with the "blocking" version
not invoking `tryRedistributeBuffers()`?
Regardless of that, it seems to me like a fragile contract if two almost
identical methods would be behaving in a quite different way. One would be
acquiring a lock and potentially deadlocking, the other not.
--
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]
