4 ms·
But I think I do care. When I see var x = await bar(); I know that other code, outside bar(), may have run during the execution of that statement. Also,
by parenthephobia 9y ago
But I think I do care.
When I see
var x = await bar();
I know that other code, outside bar(), may have run during the execution of that statement.
Also, the JS approach makes composing asynchronous operations simple:
var x = bar();
var y = bar();
return await x, await y;
Both bar invocations can run in parallel. If, say, each invocation of bar fires off an Ajax request that takes a few seconds to come back, that can be a significant saving.
It's unclear (to me) how that would be done in Lua without complicating the API.
- wruza 9y agoOpenResty, for one, allows that via grouping queries, rather than results: local requests = { "/mysql", "/postgres", "/redis", "/memcached" } local responses = { ngx.location.capture_multi(requests) } for i, response in ipairs(responses) do print(response.foobar) end But instead ngx could lazy-evaluate responses with help of metatables (see my other comment).
- gpderetta 9y agoIt is a false security. If you call a function either you know what it does (so in lua you would know whether it call yield) or you don't and it could still be calling arbitrary code, so you have to code defensively and think about reentrancy. The only reason for await is that it normally needs to save less state (a single frame) than a full coroutine yield (a whole stack). Also lua-like stackfull coroutines don't prevent firing multiple asynchronous operations at the same time (like in your example), they only make the waiting much more peasant.