Task-locals?

[Ekleog]

Continuing discussion from #14:

@Ekleog

(also, if you're aiming for feature-parity, I think task_locals are something that can't currently be implemented in a reasonable fashion without support from the executor, so it may make sense to add support for them, but I'm not sure what level of feature-parity you're trying to achieve right now, so won't open an issue straight away -- I can do if you want)

@stjepang

I'm curious - what do you need task-locals for? My guess is for logging, but thought I'd ask anyway.

In theory, task-locals can be implemented without support from the executor as a separate library. Imagine you wrap spawned futures in something like:

let task = Task::spawn(SupportTaskLocals(future));

Then, SupportTaskLocals puts task-locals inside thread-locals every time the future is polled.

Well, logging is indeed one of the use cases of task-locals, but I also was coming from https://github.com/Ekleog/erlust ; where, to best emulate erlang from rust, I needed a way to store the return-path to the current actor as a task-local -- as well as the currently configured way to reach other actors, in order to enable cross-process transparency as well as network transparency. Disclaimer though: I haven't really touched that code for a while, and am not yet sure whether I think it's a good idea any longer anyway, so…

As for the SupportTaskLocals solution… the main issue is that then, the user needs to remember to manually do it on each task spawn if they want to be able to use inter-actor communication from that task; while something supported by the executor (behind a feature flag maybe?) would make it seamless.

[dignifiedquire]

Trying to actually implement sth like this, I am realizing it would be very useful if the api from async-task could be preserved. It allows attaching a Tag to a Task. Unfortunately smol currently uses () for this task, making it impossible to use this tag. This in turn means even if I spawn(SupportTaskLocals) I can't get access to the values from the resulting smol::Task.

@dignifiedquire How about something like this?

struct SupportTaskLocals<F> {
    tag: Task,
    future: F,
}

impl<F: Future> Future for SupportTaskLocals<F> {
    type Output = F::Output;

    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        Task::set_current(&self.tag, || Pin::new(&mut self.future).poll(cx))
    }
}

impl Builder {
    pub fn spawn<F, T>(self, future: F) -> io::Result<JoinHandle<T>>
    where
        F: Future<Output = T> + Send + 'static,
        T: Send + 'static,
    {
        // Create a new task handle.
        let task = Task::new(self.name);
        let future = SupportTaskLocals { task, future };

        // <same old stuff goes here>
    }
}

Essentially, instead of using tags, you can wrap every spawned future into SupportTaskLocals, which holds the tag as a field.

[dignifiedquire]

@stjepang there is one bit missing in the <same old stuff goes here> what I am struggeling with.

I want to access the task on the result from spawn. But the result I get from calling smol::Task::spawn(future) doesn't allow me to, and so I would need to store the Task a second time on a wrapper around smol::Task, which seems quite unfortunate.

[dignifiedquire]

Okay, found a workaround for the last issue described. But now I am running in to the issue of pinning the stored Future. Any way to avoid having to Box it? that would be really unfortunate if all spawned futures would have to be boxed now :/

You can use Pin::new_unchecked() or pin_project! to make a Pin<&mut F>.

[dignifiedquire]

thanks @stjepang I am starting to forget the basics again ..

Task-locals are out scope right now so I'm going to close this issue. Thanks for your inputs, everyone!

I suggest looking at this PR for how to implement task locals on top of smol:
async-rs/async-std#757

[notgull]

I've implemented this in smol-rs/async-task#33.