this post was submitted on 06 Jun 2024
17 points (79.3% liked)
Programming
17383 readers
435 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
looks
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest
Well, it can't take a stream as input, so it's not that an output can't be provided because the input might not be fully known.
And it seems kind of odd if the aim is parallel execution.
pokes around a bit more
I don't really code in Javascript much, but as I very vaguely recall, at least in browsers, Javascript doesn't normally have the ability to do concurrent execution...there's some sort of mechanism that isolates code running in parallel, Web Workers, as I recall.
One of the things that Mozilla's docs on Promise mentions is this:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
So, one thing that you normally have to do in APIs that have cooperative multithreading going on is, if you want the system to stay responsive, is to make sure that if you're gonna yield to other threads if you're gonna be doing some work for an extended period of time. Like, say you've got something going on that's CPU-bound and something that's network-bound...you don't want to have one blocking on the other. You want to slice up the tasks and switch back and forth between them to keep the network connection saturated.
I am thinking that it's possible that the goal here is to do that. Like, you might want to be generating a hash of a big block of data, say a couple gigs. Maybe it takes Javascript a while to do that. So you generate a Promise for that computation, along for the other things you need to do, and then wait for any of them to complete.
If you don't have anything else going on in your particular codebase, then you can just immediately block until the Promise is fulfilled.
That being said, that's just my kneejerk reaction based on about a two-minute skim and some familiarity with past systems that have worked in kinda similar ways.
That seems like a good guess, I can see why async hashing could be useful. But it would be nice if there was an alternative API that was blocking so my code wouldn't get infected with async/await all over the place...
To add - blocking the main thread on a long running task in the browser can make the page unresponsive. There's not really a way, as far as I know, to "block until a promise completes", which might be the source of the frustration. It seems to me that was intentional by the ones who designed this function.