Hacker News Reader

Comment by mrkeen | Hacker News Reader

In the code example for virtual threads, I have no idea what will happen in parallel.

How do I reason about the order in which the calls change the state of the world?

That's all sequential code, it would be run inside a single "virtual thread". Note that the async code on the right is also sequential, just structured through an async API.

From my perspective they're not entirely equivalent. The async variant seems to be batching getImages and saveImages, while the sync variant gets and saves each image individually, sequentially.

They aren't perfectly equivalent because the virtual thread example uses a loop instead of the following (dropping the try/catch):

  // client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
  var response = client.send(request, HttpResponse.BodyHandlers.ofString()); 
  // .thenApply(HttpResponse::body)
  var body = response.body();
  // .thenApply(this::getImageURLs)
  var urls = getImageURLs(body);
  //  .thenCompose(this::getImages)
  var images = getImages(urls);
  // .thenAccept(this::saveImages)
  saveImages(images);

And if it had been written this way it would have been clearer that they are, in fact, equivalent. But generally people don't write like this, they use looping constructs.

Regardless, the important bit is that the parallel/concurrent bit of the async one is that it is cast off into an async system. The following execution steps are, well, steps. Each executed in sequence. Just like the body of the virtual thread example would be executed, but without the cumbersome noise of thenApply and thenCompose and such.

Reply on news.ycombinator.com