Skip to content
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

Optimize waker allocation size when type is statically known #4

Open
faern opened this issue Apr 28, 2020 · 0 comments
Open

Optimize waker allocation size when type is statically known #4

faern opened this issue Apr 28, 2020 · 0 comments

Comments

@faern
Copy link
Owner

faern commented Apr 28, 2020

When async support was introduced and the Thread instance was replaced with a ReceiverWaker, heap usage went from 8 to 24 bytes for this object. This is not a lot, but would be nice to be able to avoid it. If we know statically whether the channel should unpark a channel or wake a task it can still allocate a Thread or Waker instead of the generic ReceiverWaker.

Since it would be nice to still be able to store senders and receivers that send to both to sync threads and async tasks in the same containers it is also a requirement that senders can be generic the way they currently are.

Proposed solution (EARLY DRAFT):

pub trait WakerMode {
    type Waker;

    alloc_waker() -> *mut Waker;
}

pub struct Generic;
pub struct Sync;
pub struct Async;

pub struct Sender<T, Mode: WakerMode = Generic> {...}
pub struct Receiver<T, Mode: WakerMode = Generic> {...}

The goal is to make the generic channel work as now: Can receive both sync and async and cost 24 bytes for the waker. But allow a special Receiver<T, Sync> that will only allocate an 8 byte Thread for unparking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant