Non-Send version of callbacks such as `on_thread_park`

[Darksonn]

When using LocalRuntime, it's possible to guarantee that certain callbacks on the runtime builder only run on the current thread. So we should provide non-Send versions of those callbacks.

Note that we should have tests for this. For example, it's very important that on_thread_park only runs inside Runtime::block_on calls. If it also runs in Handle::block_on calls, then this logic does not work. There must be tests for that before non-Send versions of the callbacks can be accepted.

[aryan9600]

hello, i'd like to take a crack at this. since runtime::Config doesn't contain any non-send/sync data yet, i assume that these callbacks should be set via runtime::local_runtime::options::LocalOption? the reason i ask is because at the moment, it doesn't contain any real fields and everything is configured via runtime::Config.

[Darksonn]

Yes, it will most likely be stored in LocalOptions. It may still make sense to use the Callback type even though it requires Send. That can be bypassed with unsafe, and as long as the callback is not actually transferred across threads, it's okay.

[aryan9600]

thinking about this from the perspective of the public API, we would want the function parameter to not required Send/Sync.

impl LocalOptions {
    pub fn on_thread_park<F>(&mut self, f: F) -> &mut Self
    where
        F: Fn()
}

i think it might be better to introduce a new type LocalCallback which is a std::rc::Rc<dyn Fn()> and use that in LocalOptions. keen to hear your thoughts.

[Darksonn]

Yes, that signature looks reasonable. You probably still need F: 'static as well. Regarding having a LocalCallback type, the challenge is that internally the LocalRuntime uses the same implementation as the normal current-thread runtime, so we have to use the same type for both. But feel free to see if you can get it to work.

[aryan9600]

yes, we'll need to do some refactoring in the current thread runtime to accomoadate LocalCallback (since the implementation is Send+Sync). but the only way that i can think of using Callback while keeping the above public API is to use std::mem::transmute, so that we can cast something that isdyn Fn() to dyn Fn() + Send + Sync. since the usage of transmute is so heavily discouraged, i thought its better to refactor things. please let me know if there's a better unsafe way to do this.

[Darksonn]

You could also do something like this:

struct UnsafeSendSync<T>(T);
unsafe impl<T> Send for UnsafeSendSync<T> {}
unsafe impl<T> Sync for UnsafeSendSync<T> {}

impl<T: Fn()> UnsafeSendSync<T> {
    fn call(&self) {
        (self.0)()
    }
}

fn to_send_sync<F>(f: F) -> impl Fn() + Send + Sync
where
    F: Fn(),
{
    let f = UnsafeSendSync(f);
    move || f.call()
}