Seems like it'd be a shame to have the polled/async improvements and not include automatic buffer selection. I guess that'll be the Sunday project.
Oh. What I mean is that there's several potential *sets* of ready buffers (identified by a new union member alongside buffer_index). A RECVMSG etc specifies the set to use (buffer_index = registered_buffer = 17). If no buffer in set once ready, signal EBUSY.
-
-
Once userspace is done with a buffer used by RECVMSG, it can free the memory, or provide it again to the kernel for the set of buffers. Multiple sets because different recvmsgs might need differently sized buffers.
-
E.g. the sockets waiting for a new 'command' from client wouldn't want a large buffer, but sockets waiting for a bulk file upload would.
- 9 more replies
New conversation -
-
-
Ah ok, that makes more sense then. I kind of like that idea, seems flexible and you can manage connections into sets on the app side, or requests into sets. And the buffer is removed from the set permanently when used in the kernel, app must provide it again, so lifetime handled.
-
Precisely. Wondering if FDs for things like chained open();stat();close(); could be handled similarly. Instead of having to write BPF, which explodes the necessary toolchain.
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.