How does the loop feature work and how could it be expanded

[niklaswimmer]

The new loop feature provides access to the r#loop::new_async function and I was wondering how it works under the hood. The example calls AsyncHandle::send after pushing into the channel so I guess what really happens is that via the new_async function we can create some kind of task which is advanced everytime we call send on the returned handle. Advancing means it runs until the task yields I guess? (which would happen if we call blocking_recv and there are no items in the channel)

If those observations are correct I guess my question is on which thread that task is executed? Supposedly on the Neovim thread because we can access the lua context inside the task?

I wonder if it would be possible to make the passed in closure return a future and then poll it everytime send is called? An async executor like tokio could be used on another thread to repeatedly call send until the task completed? Is this possible? I think it would add to the feature, as currently even though the method is called new_async we can not actually use async await.

If not possible we can maybe choose a different name?

[noib3]

The example calls AsyncHandle::send after pushing into the channel so I guess what really happens is that via the new_async function we can create some kind of task which is advanced everytime we call send on the returned handle

Correct. new_async creates a callback that is managed by libuv (which Neovim uses for its event loop) and it's executed every time you call send on the handle (this is technically not always the case, if you call handle.send() multiple times before the callback is executed libuv will coalesce those into a single call. Refer to the libuv API docs for more infos).

Advancing means it runs until the task yields I guess?

No. What you pass to new_async is a regular synchronous function. There is (yet) no yielding in Rust.

which would happen if we call blocking_recv and there are no items in the channel

No. blocking_recv will simply block the thread until there's an item in the channel (as the name suggests).

Supposedly on the Neovim thread because we can access the lua context inside the task?

Yes. You can trigger the callback from any thread (AsyncHandle is Send) but it will always be executed on the Neovim thread.

I wonder if it would be possible to make the passed in closure return a future and then poll it everytime send is called?

Probably not. There's no way to poll anything via handle.send(). uv_async_send simply registers the callback to be executed on the next tick of the event loop and returns immediately. Passing and polling futures is fundamentally incompatible with the underlying C api that we're using.

What you could do is create a new single threaded tokio runtime, move it inside the closure passed to new_async and runtime.block_on an async {} block. However that'll still block the Neovim thread until the whole async block has finished.

even though the method is called new_async we can not actually use async await. If not possible we can maybe choose a different name?

It might be a little misleading but I followed the original libuv naming, just like every function in nvim_oxi::api is named after its counterpart in vim.api.