Seamless async integration in JS library code

[sbc100]

While reviewing #25523 it occurred to me that we should able to avoid the custom proxying code being added there.

When we have JS library functions such as select or poll (or even read and write) then can have optional blocking. i.e. They should be able "block" whenever they are called from a pthread.

The only time they cannot block is when they are called from the main thread (and we don't have JSPI or ASYNCIFY enabled).

Considering just the pthread/worker use case we should be able detect if that originator of the calls was a worker and return promise in the case.

e.g.

if (callerIsWorker) {
   return new Promise(...);
} else {
   return EWOULDBLOCK  (or ENOSYS);
}

Perhaps we could extend the existing __async attribute to mean async where possible. These function could return a promise when its OK to do so (i.e. when proxied from a pthread) and return a value (i.e. EWOULDBLOCK) when run on the main thread.

[sbc100]

CC @brendandahl @kripken @dschuff

[sbc100]

I think I'll start by seeing if I can add builtin support for the custom proxying added in #25523

[brendandahl]

I'd lean towards adding a different attribute for that type of behavior. There are probably use cases where you don't want to block in a worker and still use JSPI.

[sbc100]

I'd lean towards adding a different attribute for that type of behavior. There are probably use cases where you don't want to block in a worker and still use JSPI.

Really? It seems like you would want to emulate the JSPI behaviour when running in a worker, no? Can you give an example of when you would not want this?

[brendandahl]

Errr... I read this backwards. I thought you wanted to block by default in a pthread. Nevermind.

[sbc100]

Yes, I think that is what I am saying isn't it? Just like JSPI "blocks" until the promise resolves we can effectively "block" a worker until the main thread is done with its work right? From the C code's POV we can get JSPI like behaviour when running in a thread, right?

[sbc100]

Another way of putting it: When a JS library call is proxied to the main thread we should be free use as much async-style coding as we want.. there is no need to the proxied work not use async/await/promises, right?

This means that we can think of "proxied function" and "JSPI functions" in the same way, i think? In both cases we are free'd from the normal limitation of having to return the result synchronously.