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 io2,
CompletionQueue io3, int fea) {
this.ioUringSubmissionQueue = io2;
this.ioUringCompletionQueue = io3;
this.features = fea;
}
/**
* Enable ring. This method must be called from the same method that will call {@link SubmissionQueue#submit()} and
* {@link SubmissionQueue#submitAndWait()}.
*/
void ena() {
// 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() {
return ioUringCompletionQueue.ringFd;
}
int fea() {
return features;
}
SubmissionQueue io() {
return this.ioUringSubmissionQueue;
}
CompletionQueue io2() {
return this.ioUringCompletionQueue;
}
void clo() {
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 has minimal nesting and short methods, but readability is severely hampered by cryptic naming conventions. Parameters like `io2`, `io3`, and `fea`, along with method names like `ena()`, `fea()`, `io()`, `io2()`, and `clo()`, obscure intent. These abbreviations require external knowledge or repeated context-switching to understand. The constructor parameter names (`io2`, `io3`) are particularly poor, and the method `io2()` returning a CompletionQueue is misleading. Field names are mostly clear except `features` being shortened to `fea` in methods. Action granularity is acceptable, but code structure suffers because the abbreviated names make the logic feel tangential and hard to follow. The comments help somewhat, but they do not compensate for the opaque identifiers. Overall, the code is concise but not readable without prior context.
Run 2
The code suffers from severely poor naming (io2, io3, fea, ena, clo, fea, io, io2) that obscures intent and forces readers to infer meaning. Method and parameter names violate Java conventions and fail to communicate purpose. The class structure is relatively flat, and action granularity is mostly reasonable, but the abbreviated names break reading flow. Some comments exist but are not enough to compensate for cryptic identifiers. Field types are clear, but the constructor's shortened names and methods like `io()` and `io2()` create ambiguity about which queue is which. Overall, the code is readable only with significant effort and prior knowledge, making it closer to unreadable on the provided scale.
Run 3
The code has some structure but suffers from poor readability. Method names like 'ena', 'fd', 'fea', 'io', 'io2', and 'clo' are cryptic abbreviations that obscure intent. Parameter names like 'io2' and 'io3' add confusion. The field names are reasonably clear, but the abbreviated method names negate this. Structure is mostly flat, which is good, and each method performs a single action. However, the lack of descriptive naming makes the code hard to understand without external documentation. Comments explain some operations but don't compensate for the obscure naming. Overall, the code is functional but not readable.
Run 1
Code Structure: Fields, constructor, accessors, initialization, and cleanup are logically organized into small methods. Nesting: Almost entirely flat; the early return in cleanup avoids unnecessary nesting. Clarity of intent: Descriptive field names and comments help, but abbreviated method names such as ena(), fea(), io(), io2(), and clo(), along with constructor parameters io2, io3, and fea, obscure purpose. The enable-method documentation also confusingly says 'same method' where the implementation comment says 'same thread.' Code length: Compact, with little unnecessary code. Action granularity: Each statement performs a single action, and the lengthy native-call arguments are separated clearly across lines. Reading flow: Generally natural and easy to scan, although cryptic naming and the low-level, eight-argument cleanup call require extra interpretation.
Run 2
Code Structure: Fields, initialization, accessors, and lifecycle operations are logically organized into small methods. Nesting: Minimal nesting; the early return in clo() keeps cleanup flat. Clarity of intent: Descriptive field names and comments help, but abbreviated methods (ena, fea, io, io2, clo) and parameters (io2, io3, fea) obscure purpose. The enable-method documentation confusingly says 'same method' while its comment specifies 'same thread.' Code length: Concise overall, with little unnecessary code; the lengthy native cleanup call reflects its argument requirements. Action granularity: Each statement performs a single action, and cleanup arguments are individually formatted. Reading flow: Initialization and lifecycle steps are easy to follow, though cryptic naming interrupts comprehension and makes the two queue accessors harder to distinguish.
Run 3
Code Structure: The class logically groups ring state, initialization, accessors, enabling, and cleanup. Nesting: Minimal nesting and an early return keep control flow straightforward. Clarity of intent: Descriptive field names and comments help, but abbreviated methods such as ena(), fea(), io(), io2(), and clo(), plus parameters io2, io3, and fea, obscure purpose. The enable documentation also says 'same method' while the implementation comment says 'same thread', creating ambiguity. Code length: Compact, with little unnecessary code; the long native cleanup call reflects its argument requirements. Action granularity: Statements generally perform one action per line, and the multiline native call is easy to scan. Reading flow: Constructor-to-operations organization is natural, though cryptic accessor names and repeated long field references slow comprehension.