Skip to content

Commit 012dd22

Browse files
committed
init
1 parent 2884f33 commit 012dd22

File tree

4 files changed

+405
-2
lines changed

4 files changed

+405
-2
lines changed

.gitignore

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
.git/
2+
.DS_Store

README.md

Lines changed: 316 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,316 @@
1-
# neovim_async_tutorial
2-
Introducing async await to lua
1+
# Neovim Async Tutorial (lua)
2+
3+
## Preface
4+
5+
This tutorial assumes that you are familiar with the concept of `async` `await`
6+
7+
You will also need to read through the [first 500 words](https://www.lua.org/pil/9.1.html) of how coroutines work in lua.
8+
9+
## [Luv](https://github.com/luvit/luv)
10+
11+
Neovim use [libuv](https://github.com/libuv/libuv) for async, the same monster that is the heart of NodeJS.
12+
13+
The `libuv` bindings are exposed through `luv` for lua, this is accessed using `vim.loop`.
14+
15+
Most of the `luv` APIs are similar to that of NodeJS, ie in the form of
16+
17+
`API :: (param1, param2, callback)`
18+
19+
Our goal is avoid the dreaded calback hell.
20+
21+
## Preview
22+
23+
```lua
24+
local a = require "async"
25+
26+
local do_thing = a.sync(function (val)
27+
local o = a.wait(async_func())
28+
return o + val
29+
end)
30+
31+
local main = a.sync(function ()
32+
local thing = a.wait(do_thing()) -- composable!
33+
34+
local x = a.wait(async_func())
35+
local y, z = a.wait_all{async_func(), async_func()}
36+
end)
37+
38+
main()
39+
```
40+
41+
## [Coroutines](https://www.lua.org/pil/9.1.html)
42+
43+
If you don't know how coroutines work, go read the section on generators on [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators).
44+
45+
It is in js, but the idea is identical, and the examples are much better.
46+
47+
---
48+
49+
Here is an example of coroutines in Lua:
50+
51+
Note that in Lua code `coroutine` is not a coroutine, it is an namespace.
52+
53+
To avoid confusion, I will follow the convention used in the Lua book, and use `thread` to denote coroutines in code.
54+
55+
```lua
56+
local co = coroutine
57+
58+
local thread = co.create(function ()
59+
local x, y, z = co.yield(something)
60+
return 12
61+
end)
62+
63+
local cont, ret = co.resume(thread, x, y, z)
64+
```
65+
66+
---
67+
68+
Notice the similarities with `async` `await`
69+
70+
In both `async` `await` and `coroutines`, the LHS of the assignment statements receives values from the RHS.
71+
72+
This is how it works in all synchronous assignments. Except, we can defer the transfer of the values from RHS.
73+
74+
The idea is that we will make RHS send values to LHS, when RHS is ready.
75+
76+
## Synchronous Coroutines
77+
78+
To warm up, we will do a synchronous version first, where the RHS is always ready.
79+
80+
Here is how you send values to a coroutine:
81+
82+
```lua
83+
co.resume(thread, x, y, z)
84+
```
85+
86+
---
87+
88+
The idea is that we will repeat this until the coroutine has been "unrolled"
89+
90+
```lua
91+
local pong = function (thread)
92+
local nxt = nil
93+
nxt = function (cont, ...)
94+
if not cont
95+
then return ...
96+
else return nxt(co.resume(thread), ...)
97+
end
98+
end
99+
return nxt(co.resume(thread))
100+
end
101+
```
102+
103+
---
104+
105+
if we give `pong` some coroutine, it will recursively run the coroutine until completion
106+
107+
```lua
108+
local thread = co.create(function ()
109+
local x = co.yield(1)
110+
print(x)
111+
local y, z = co.yield(2, 3)
112+
print(y)
113+
end)
114+
115+
pong(thread)
116+
```
117+
118+
We can expect to see `1`, `2 3` printed.
119+
120+
## [Thunk](https://stackoverflow.com/questions/2641489/what-is-a-thunk)
121+
122+
Once you understand how the synchronous `pong` works, we are super close!
123+
124+
But before we make the asynchronous version, we need to learn one more simple concept.
125+
126+
For our purposes a `Thunk` is function whose purpose is to invoke a callback.
127+
128+
i.e. It adds a transformation of `(arg, callback) -> void` to `arg -> (callback -> void) -> void`
129+
130+
```lua
131+
local read_fs = function (file)
132+
local thunk = function (callback)
133+
fs.read(file, callback)
134+
end
135+
return thunk
136+
end
137+
```
138+
139+
---
140+
141+
This too, is a process that can be automated:
142+
143+
```lua
144+
local wrap = function (func)
145+
local factory = function (...)
146+
local params = {...}
147+
local thunk = function (step)
148+
table.insert(params, step)
149+
return func(unpack(params))
150+
end
151+
return thunk
152+
end
153+
return factory
154+
end
155+
156+
local thunk = wrap(fs.read)
157+
```
158+
159+
So why do we need this?
160+
161+
## Async Await
162+
163+
The answer is simple! We will use thunks for our RHS!
164+
165+
---
166+
167+
With that said, we will still need one more magic trick, and that is to make a `step` function.
168+
169+
The sole job of the `step` funciton is to take the place of the callback to all the thunks.
170+
171+
In essence, on every callback, we take 1 step forward in the coroutine.
172+
173+
```lua
174+
local pong = function (thread, callback)
175+
local step = nil
176+
step = function (...)
177+
local go, ret = co.resume(thread, ...)
178+
if not go then
179+
assert(co.status(thread) == "suspended", ret)
180+
elseif type(ret) == "function" then
181+
ret(step)
182+
else
183+
(callback or function () end)(ret)
184+
end
185+
end
186+
step()
187+
end
188+
189+
```
190+
191+
Notice that we also make pong call a callback once it is done.
192+
193+
---
194+
195+
We can see it in action here:
196+
197+
198+
```lua
199+
local echo = function (...)
200+
local args = {...}
201+
local thunk = function (step)
202+
step(unpack(args))
203+
end
204+
return thunk
205+
end
206+
207+
local thread = co.create(function ()
208+
local x, y, z = co.yield(echo(1, 2, 3))
209+
print(x, y, z)
210+
local k, f, c = co.yield(echo(4, 5, 6))
211+
print(k, f, c)
212+
end)
213+
214+
pong(thread)
215+
```
216+
217+
We can expect this to print `1 2 3` and `4 5 6`
218+
219+
Note, we are using a synchronous `echo` for illustration purposes. It doesn't matter when the `callback` is invoked. The whole mechanism is agnostic to timing.
220+
221+
You can think of async as the more generalized version of sync.
222+
223+
You can run an asynchronous version in the last section.
224+
225+
## Await All
226+
227+
One more benefit of thunks, is that we can use them to inject arbitrary computation.
228+
229+
Such as joining together many thunks.
230+
231+
```lua
232+
local join = function (thunks)
233+
local len = table.getn(thunks)
234+
local done = 0
235+
local acc = {}
236+
237+
local thunk = function (step)
238+
if len == 0 then
239+
return step()
240+
end
241+
for i, tk in ipairs(thunks) do
242+
local callback = function (...)
243+
acc[i] = {...}
244+
done = done + 1
245+
if done == len then
246+
step(unpack(acc))
247+
end
248+
end
249+
tk(callback)
250+
end
251+
end
252+
return thunk
253+
end
254+
```
255+
256+
This way we can perform `await_all` on many thunks as if they are a single one.
257+
258+
## More Sugar
259+
260+
All this explicit handling of coroutines are abit ugly. The good thing is that we can completely hide the implementation detail to the point where we don't even need to require the `coroutine` namespace!
261+
262+
Simply wrap the coroutine interface with some friendly helpers
263+
264+
```lua
265+
local pong = function (func, callback)
266+
local thread = co.create(func)
267+
...
268+
end
269+
270+
local await = function (defer)
271+
return co.yield(defer)
272+
end
273+
274+
local await_all = function (defer)
275+
return co.yield(join(defer))
276+
end
277+
```
278+
279+
## Composable
280+
281+
At this point we are almost there, just one more step!
282+
283+
```lua
284+
local sync = wrap(pong)
285+
```
286+
287+
We `wrap` `pong` into a thunk factory, so that calling it is no different than yielding other thunks. This is how we can compose together our `async` `await`.
288+
289+
It's thunks all the way down.
290+
291+
## Tips and Tricks
292+
293+
In Neovim, we have something called `textlock`, which prevents many APIs from being called unless you are in the main event loop.
294+
295+
This will prevent you from essentially modifying any Neovim states once you have invoked a `vim.loop` funciton, which run in a seperate loop.
296+
297+
Here is how you break back to the main loop:
298+
299+
```lua
300+
local main_loop = function (f)
301+
vim.schedule(f)
302+
end
303+
```
304+
305+
```lua
306+
local run = a.sync(function ()
307+
-- do something in other loop
308+
a.wait(main_loop)
309+
-- you are back!
310+
end)
311+
```
312+
313+
314+
## Practice!
315+
316+
I have bundle up this tutorial as a vim plugin, you can install it the usual way.

0 commit comments

Comments
 (0)