-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kevent() requires a Vec for its event list, when instead it should probably take a slice #1043
Comments
For extra context: I'm porting the network poller setup for https://github.com/inko-lang/inko from the "polling" crate back to direct usage of epoll/kqueue/etc (inko-lang/inko#344 (comment) for more details as to why). Back in ye olde days I used the "nix" crate to interact with kqueue (https://github.com/inko-lang/inko/blob/87b36927d7bd3194e9da90e406f5206d8c713636/vm/src/network_poller/kqueue.rs). Given that I'm already using the rustix crate and long since stopped using the "nix" crate, I'd like to be able to use rustix for this as well, but using a stack allocated array as the old network polling code did. |
This removes the need for dynamically allocating a Vec when the kevent() function is called. The documentation is also rephrased slightly as slices don't really have a "capacity", but only a fixed-size length. This fixes bytecodealliance#1043.
This removes the need for dynamically allocating a Vec when the kevent() function is called. The documentation is also rephrased slightly as slices don't really have a "capacity", but only a fixed-size length. This fixes bytecodealliance#1043.
I suggest to follow the API of |
The wrapper for
kevent()
is defined as follows:Here the
eventlist
argument is defined as&mut Vec<Event>
, requiring a heap allocating of aVec
on every call. For a system where file descriptors are frequently (un)registered (e.g. a busy socket server), it's not unlikely for theVec
allocations to become a bit of a problem.Would it be possible to change the signature such that
eventlist
is a&mut [Event]
instead? This way one can simply stack allocate the slice, and still use aVec
if deemed necessary (e.g. one is expecting many events).Some of this was discussed in #578, but it seems nothing was done in response.
The text was updated successfully, but these errors were encountered: