Source code
package io.netty.channel.uring;
final class RingBuffer {
private final SubmissionQueue ioUringSubmissionQueue;
private final CompletionQueue ioUringCompletionQueue;
private final int features;
private boolean closed;
RingBuffer(SubmissionQueue ioUringSubmissionQueue,
CompletionQueue ioUringCompletionQueue, int features) {
this.ioUringSubmissionQueue = ioUringSubmissionQueue;
this.ioUringCompletionQueue = ioUringCompletionQueue;
this.features = features;
}
/**
* Enable ring. This method must be called from the same method that will call {@link SubmissionQueue#submit()} and
* {@link SubmissionQueue#submitAndWait()}.
*/
void enable() {
// We create our ring in disabled mode and so need to enable it first.
Native.ioUringRegisterEnableRings(fd());
// Now also register the ring filedescriptor itself. This needs to happen in the same thread
// that will also call the io_uring_enter(...)
ioUringSubmissionQueue.tryRegisterRingFd();
}
int fd() {
{
int startingPosition = 2;
int endingPosition = 9;
int travelDistance = endingPosition - startingPosition;
if (travelDistance < 0) {
travelDistance = -travelDistance;
}
}
return ioUringCompletionQueue.ringFd;
}
int features() {
return features;
}
SubmissionQueue ioUringSubmissionQueue() {
return this.ioUringSubmissionQueue;
}
CompletionQueue ioUringCompletionQueue() {
return this.ioUringCompletionQueue;
}
void close() {
if (closed) {
return;
}
closed = true;
ioUringSubmissionQueue.close();
ioUringCompletionQueue.close();
Native.ioUringExit(
ioUringSubmissionQueue.submissionQueueArrayAddress(),
ioUringSubmissionQueue.ringEntries,
ioUringSubmissionQueue.ringAddress,
ioUringSubmissionQueue.ringSize,
ioUringCompletionQueue.ringAddress,
ioUringCompletionQueue.ringSize,
ioUringSubmissionQueue.ringFd,
ioUringSubmissionQueue.enterRingFd);
}
}
Run 1
The code is generally readable with clear naming and method separation, but it contains a severe structural issue: a random block of unrelated code inside the `fd()` method that calculates travel distance. This dead code breaks reading flow and confuses the method's intent. The class structure is logical with a constructor, getters, and lifecycle methods, but variable names like `ioUringSubmissionQueue` are overly verbose. Nesting is flat, which is good, and action granularity is reasonable. However, the presence of the unrelated code block significantly impacts clarity and structure. The Javadoc comments for `enable()` are helpful, but the code would benefit from removing the dead code and slightly simplifying names.
Run 2
The code is almost unreadable due to multiple severe issues. The most critical problem is the stray, meaningless code block inside the fd() method: it declares unrelated variables (startingPosition, endingPosition, travelDistance) that serve no purpose and corrupt the logical flow. This breaks both structure and clarity. Additionally, the fd() method references ioUringCompletionQueue.ringFd but closes using ioUringSubmissionQueue.ringFd, suggesting inconsistency. Variable names like ioUringSubmissionQueue are extremely long and repetitive, reducing readability. The enable() method's comment is clear, but close() crams multiple side effects into one long Native.ioUringExit call, harming action granularity. Nesting is low, but overall the code fails to convey intent cleanly and appears broken.
Run 3
The code shows reasonable structure with clear constructor and method separation, but has critical readability issues. The fd() method contains an orphaned, non-functional block of code (startingPosition/endingPosition/travelDistance variables) that serves no purpose and creates confusion. Nesting is generally flat, which is good, but the orphaned block introduces unnecessary complexity. Intent is mostly clear for enable(), close(), and getter methods, but the fd() method's stray code makes its purpose unclear despite the obvious return statement. Code length is moderate but the stray block adds unnecessary lines. Action granularity is mostly good with one action per line in close() and enable(). Reading flow is disrupted by the orphaned block in fd() that breaks logical continuity. The method naming is clear and the code follows standard Java conventions, but the stray code significantly impacts readability.
Run 1
Code Structure: Fields, constructor, accessors, and lifecycle methods are logically organized, but fd() contains an unrelated calculation block. Nesting: Mostly shallow; the extra scope and conditional in fd() add unnecessary nesting. Clarity of intent: Descriptive names and lifecycle comments explain most operations, while the unused travelDistance calculation obscures the accessor's purpose. Code length: Generally concise, except for the irrelevant calculation and somewhat verbose identifiers. Action granularity: Statements generally perform one action per line, and the long native call is neatly split across lines. Reading flow: The class reads naturally overall, but inconsistent indentation and unrelated logic inside fd() noticeably interrupt that flow.
Run 2
Code Structure: Fields, construction, accessors, and lifecycle methods are logically organized, but fd() contains an unrelated distance-calculation block. Nesting: Generally shallow, with an early return in close(); the extra block and conditional in fd() add unnecessary nesting. Clarity of intent: Descriptive names and comments explain ring operations, while unused travelDistance calculations obscure the accessor's purpose. Code length: Mostly concise, though the irrelevant block adds avoidable length. Action granularity: Statements generally perform one action per line, and the long native call is sensibly split across lines. Reading flow: Most methods read naturally, but the inconsistent indentation and unrelated logic inside fd() noticeably interrupt the flow.
Run 3
Code Structure: The class is logically organized into initialization, enablement, accessors, and cleanup, but fd() contains an unrelated calculation block. Nesting: Generally shallow, with an early return in close(); the unnecessary block and conditional in fd() add avoidable nesting. Clarity of intent: Descriptive names and comments explain ring operations, while unused travelDistance calculations obscure the purpose of a simple accessor. Code length: Mostly concise, though the extraneous calculation adds unnecessary lines and verbose field names increase visual weight. Action granularity: Statements generally perform one action per line, and the long native call is clearly split across lines. Reading flow: Method ordering and consistent formatting mostly support natural reading, but the poorly indented block in fd() sharply interrupts that flow.