Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

V8 adds support for top-level await

chromium.googlesource.com

Post reply on HN
Print view View original

201–210 of 310 posts

Re: V8 adds support for top-level await

#201

Post by nitely »

esprehn wrote: post #180
nitely wrote: post #170

Earlier quoted context omitted.

That would unblock all coroutines waiting for the promise, instead of just the first one. It's not that trivial, that's the point.

For queued ordering instead of unblocking everyone at once you can reassign the Promise. let lock = Promise.resolve() const wait = (callback) => lock = lock.then(() => callback()); Until the callback resolves the lock is held, so you can do: wait(async () => { await step1(); await step2(); // release the lock. });

If the callback throws an error, none of the awaiting coroutines will run, and adding a catch would break the callback error propagation.

Re: V8 adds support for top-level await

#202

Post by inglor »

hombre_fatal wrote: post #133
Arelius wrote: post #115

Earlier quoted context omitted.

Do you really want to block all of your http calls on the result of the prior call in the off-chance that they might share a result just so you can only cache the results and not the promises? The reason we don't have a mutex in javascript is that there are better solutions to the problems it solves.

Maybe I don't understand your response, but a map of promises to handle parallel in-flight requests for the same resource (which the grandparent pitched) is basically the most elegant yet simple solution to this common problem. I don't really see how it's a mutex though, you're just returning the same promise to multiple requests. It's far simpler and doesn't use a locking construct.

A promise is a lock in that resolving it is the 'release' and awaiting it is `acquire`.

For example:

``` let release; const acquire = new Promise(resolve => release = resolve);

(async () => {

  await acquire;
  // use here
  release(); // now others can use it
})(); ```

This is a bit different because multiple people can await the lock here so it's like a "one time multicast mutex" making it more akin to condition variables.

That said - thinking about it as a mutex is a really backwards way in my opinion.

Re: V8 adds support for top-level await

#203

Post by nitely »

wayneftw wrote: post #187
nitely wrote: post #170

Earlier quoted context omitted.

That would unblock all coroutines waiting for the promise, instead of just the first one. It's not that trivial, that's the point.

You moved the goal posts on me. But the solution for your next scenario is actually pretty trivial though isn’t it? You don’t really need what you call locking in a single-threaded world. You just need a state machine.

No, I didn't. That's how a lock works. Only one coroutine (or thread) is allowed to hold it at a time while the others must await their turn. A state machine is a lot more than a boolean variable.

Re: V8 adds support for top-level await

#204

Post by jcelerier »

jnbiche wrote: post #101
londons_explore wrote: post #19

All this async code without decent locking primitives is leading to a rabbit hole of race conditions... It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state. I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of…

Javascript devs, for all their flaws, understand async programming far, far better than the average C programmer. Indeed, your assertion that we need "locking primitives" to counteract "race conditions" is evidence of that. Yes, JavaScript can have race conditions, but not multi-threaded race conditions that cause resource contention [0]. So what good would locking primitives be? And as a solution to single-threaded…

> (also ignorant, because 1990s C was decidedly synchronous)

unless you were programming in... any GUI toolkit ever except the most toy ones ? even win 3.1 GUI primitives were async

Re: V8 adds support for top-level await

#205

Post by pjmlp »

londons_explore wrote: post #19

All this async code without decent locking primitives is leading to a rabbit hole of race conditions... It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state. I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of…

Have C programmers already learned how to do memory management properly? Apparently 50 years have not been enough.

Don't assume all programming languages have the same design flaws as C.

Re: V8 adds support for top-level await

#206

Post by eurasiantiger »

tudorconstantin wrote: post #126
_bxg1 wrote: post #48

Earlier quoted context omitted.

Data races are impossible in JavaScript because it's single-threaded. Race conditions are possible in any language that can do anything asynchronous, which is basically all of them. But the general benefit you get from JS being single-threaded is the fact that any given callback is transactional. No other code will ever come in and mutate state between two regular lines of JavaScript code. Achieving this is pretty mu…

Since an async function is simply a function that returns a promise is there actually any difference between using async/await and using promises explicitly?

Terseness and readability towards less asynchronously minded folk

Re: V8 adds support for top-level await

#207

Post by pjmlp »

colordrops wrote: post #199
londons_explore wrote: post #19

All this async code without decent locking primitives is leading to a rabbit hole of race conditions... It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state. I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of…

Plenty of people replied to counter this misinformation, so why is it still at the top?

Too many C devs upvoting it, I guess.

Re: V8 adds support for top-level await

#208

Post by matharmin »

kbenson wrote: post #79
PetahNZ wrote: post #70

Earlier quoted context omitted.

One use case I often find is a caching layer between JS and a HTTP call. If there are 2 calls to a non cached endpoint, the HTTP will fire off twice before caching the result. You can work around this by returning the first promise from the cache, but this is essentially a mutex. Having locking primitives would solve this and require less boilerplate code.

Seems like you should be able to build a lock mechanism fairly simply with async/await, but I agree, it would be nice if it was a built in primitive. It does feel a little silly to implement a lock function when the engine much be using one to support its async functionality in the first place, so you're introducing a lot of inefficiency.

Implementing a mutex is very simple and efficient in JavaScript - probably much lower overhead than the Promises itself.

Re: V8 adds support for top-level await

#209

Post by matharmin »

jnbiche wrote: post #141
PetahNZ wrote: post #70

Earlier quoted context omitted.

One use case I often find is a caching layer between JS and a HTTP call. If there are 2 calls to a non cached endpoint, the HTTP will fire off twice before caching the result. You can work around this by returning the first promise from the cache, but this is essentially a mutex. Having locking primitives would solve this and require less boilerplate code.

You write this boilerplate to avoid one extra non-cached HTTP call on a (browser?) client? Am I understanding correctly?

It's really not a lot of boilerplate - once you have the small utility function, it can be one additional line of code.

Re: V8 adds support for top-level await

#210

Post by matharmin »

ihuman wrote: post #81
_bxg1 wrote: post #48

Earlier quoted context omitted.

Data races are impossible in JavaScript because it's single-threaded. Race conditions are possible in any language that can do anything asynchronous, which is basically all of them. But the general benefit you get from JS being single-threaded is the fact that any given callback is transactional. No other code will ever come in and mutate state between two regular lines of JavaScript code. Achieving this is pretty mu…

> when you use async/await instead of promises or callbacks, things do change because two sequential lines of code are no longer two truly sequential instructions I thought async/await was just syntactic sugar for promises?

Yes. I think what is meant here, is that two sequential lines with `await` in them are no longer sequential instructions, and other code may execute in between them.

If you were using promises or callbacks it would be the same, except that it won't appear like two sequential lines anymore.

Post reply on HN