-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Enchancement -- add recv_many for mpsc channels? #5844
Comments
|
My proposed approach in chan.rs provides only modest optimization over what is there already. It basically pops each item off the list as the old recv method does, but is able to pre-allocate memory and free semaphores in a single update. |
I see. |
It's true that this could act as an optimization, but I'm not convinced that this is enough to justify adding yet another method. |
In Castor Actors the low-level actor processes a list of messages in bulk; single-message "Simple" actors essentially iterate on the available list. Here, recv_many enables a similar approach; I see a specific throughput benefit where they may be a series of slow external update operations and only the last matters. An alternative might be to have a channel with an effective queue size of 1 -- send would not block and would replace the existing item, if present. But: this approach necessitates as many channels as there are things to update. |
I updated my experimental recv_many implementation with substantially two changes:
The benchmarks are based on benches/sync_mpsc.rs; the test The tests Commit is here with recently rebased changes: |
poll_recv_many is not exposed, can you expose it, too? Similar as poll_recv. @aschweig |
Inspired by Alice Ryhl's Actors with Tokio it occurs to me that the mpsc channels might support batch receipt of messages.
Circumstances can exist where multiple messages are queued for the receiver by the time the receiving task runs -- and the receiving task may benefit from batch as opposed to item-by-item delivery, e.g., update a row based on a primary key but only the most recent update is needed. I propose a new method,
recv_many
, that enables the receiver to process effectively all available messages -- in this example allowing more efficient last-first processing. The public signature in bounded.rs and unbounded.rs would replace recv's Option with a Vec:pub async fn recv_many(&mut self) -> Vec<T>
I have pushed one possible implementation of the feature.
This commit adds
fn peek
to sync/mpsc/list.rs andfn num_acquired
&add_permits
to the chan.rs Semaphore trait; the latter two additions to minimize reallocations and semaphore updates.The text was updated successfully, but these errors were encountered: