Why is `crypto.subtle.digest` async?
from firelizzard@programming.dev to programming@programming.dev on 06 Jun 16:59
https://programming.dev/post/15148247

Why is crypto.subtle.digest designed to return a promise?

Every other system I’ve ever worked with has the signature hash(bytes) => bytes, yet whatever committee designed the Subtle Crypto API decided that the browser version should return a promise. Why? I’ve looked around but I’ve never found any discussion on the motivation behind that.

#programming

threaded - newest

tal@lemmy.today on 06 Jun 17:17 next collapse

looks

developer.mozilla.org/en-US/docs/Web/…/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:

developer.mozilla.org/en-US/docs/Web/…/Promise

The Promise class offers four static methods to facilitate async task concurrency

Note that JavaScript is single-threaded by nature, so at a given instant, only one task will be executing, although control can shift between different promises, making execution of the promises appear concurrent. Parallel execution in JavaScript can only be achieved through worker threads.

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.

TehPers@beehaw.org on 06 Jun 19:22 next collapse

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.

firelizzard@programming.dev on 07 Jun 00:19 collapse

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…

vzq@lemmy.blahaj.zone on 06 Jun 17:41 next collapse

It’s standard for operations that take a while and can be performed asynchronously.

What’s your problem with it?

firelizzard@programming.dev on 07 Jun 00:21 collapse

async/await infecting all of my code, being unable to create a get myField() method that involves a hash calculation. It may be standard to do heavy lifting concurrently, but async hash functions are certainly not standard in any of the languages I’ve used (which is quite a few).

vzq@lemmy.blahaj.zone on 07 Jun 05:55 collapse

From browsing your other comments on this thread I understand that you are in a context where you can’t await, that you expect the invocation to take very little time, and that the library offers no complementary sync interface.

As far was I know you’re stuck in this case. I consider the stubborn refusal to add “resolve this promise synchronously right now” a major flaw in js.

DmMacniel@feddit.de on 07 Jun 06:27 collapse

Given the nature of JS running only on a single thread. Promises/asynchronity is the only way to keep the browser from locking up.

Thus insisting on any other way is a major flaw in the developer not the language.

vzq@lemmy.blahaj.zone on 07 Jun 10:28 collapse

Thus insisting on any other way is a major flaw in the developer not the language.

I mean, I understand the idea, but this is a pretty asshole way to frame it. I don’t think I deserve that, and certainly OP doesn’t deserve that.

[deleted] on 07 Jun 15:36 collapse

.

Technus@lemmy.zip on 06 Jun 19:29 next collapse

It executes on a native thread in the background. That way it doesn’t stall the Javascript execution loop, even if you give it a gigabyte of data to hash.

DmMacniel@feddit.de on 06 Jun 19:31 collapse

its a good idea to be as non blocking as possible especially on time and resource consuming tasks like IO, cryptography, …

just use await in an async function.

firelizzard@programming.dev on 07 Jun 00:23 collapse

just use await in an async function.

Sure, I’ll just put await and async everywhere. Oh wait, I can’t. A constructor can’t be async so now I need to restructure my code to use async factories instead of constructors. Wonderful…

DmMacniel@feddit.de on 07 Jun 03:46 next collapse

Sounds like an architectural issue to begin with. A constructor shouldn’t do the heavy lifting to begin with.

firelizzard@programming.dev on 07 Jun 05:21 collapse

You consider calculating the hash of a few bytes to be heavy lifting?

DmMacniel@feddit.de on 07 Jun 06:25 collapse

The API doesn’t restrict the amount of bytes to be hashed. So yeah it’s still heavy lifting.

Trigger a loading event after the constructor is finished that the view model takes to calculate your hash.

vzq@lemmy.blahaj.zone on 07 Jun 12:21 collapse

A constructor can’t be async so now I need to restructure my code to use async factories instead of constructors

It sounds like you’re trying to do OOD/OOP. In js that’s usually not the way to go. You might want to restructure into a more functional architecture anyway.