Feda /dev/ - No Javascript allowed

#35394 Si alguien no sabe la diferencia entre ocurrencia y paralelismo va mal.

Voy a caer en el bait de desu: Asíncrono no tiene nada que ver con paralelo, al igual que concurrente. Dos tareas, funciones o como quieras llamarlo, concurrentes pueden ejecutarse a la vez una en cada core (paralelo) o no, suspendiendo la ejecución de una para dar paso a la otra y así.

De hecho el problema de los mutex que hablabamos el otro día es que te cargas el paralelismo para hacerlo simplemente concurrente porque metes dependencias entre tareas así que una va a tener que esperar a que otra termine. Además a nivel de switch de contextos y demás es bastante costoso.

Async es que simplemente haces un deferred a la ejecución de la terea y dejas al engine su gestión. Y esto no lo sé pero estoy seguro que async/await en la V8 se utiliza para generar grafos internos de dependencias entre promesas y darle un orden a la ejecución. Quizá @desu lo sepa mejor.

#35402 no lo se mejor. lo se. no te quiero insultar, no eres uno de los targets habituales.

pero el async no tiene nada que ver con el scheduler. el scheduler esta por encima del async. precisamente ahi esta el error que comete la gente y por eso te sale hablar de paralelismo.

para explicar async tansolo hay que explicar que la diferencia con una funcion "normal"...

que cojones tendra que ver el entorno de ejecucion? es como explicar la diferencia entre un int y un []int y empezar a hablar de un patron de dis;eo que los usa. y la gente normalmente tambien suele explicar mal el patron de dise;o, porque ni sabe como funciona async, ni sabe como funciona un scheduler.

#35403 mucha sobre ingenieria que no vale para mucho.

el problema es que los pferos siempre haceis esto sin pensar en que cojones haceis:

FooController => FooService => FooRepository => FooTable
BarController => BarService => BarRepository => BarTable

xq normalizas? xq no escribes codigo para resopdner a tu caso de uso?

el fpero medio no tiene cerebro para estar en contra del status quo de patrones de dise;o que le han ense;ado en su bootcamp de mierda.

#35405MTX_Anubis:

Comenta como funciona la V8 en este tema.

no se las diferencias entre todos los compiladores/runtimes. yo entiendo que todos son iguales o muy parecidos. lo que cambia es como estan representados en el compilador y los metadatos asociados. yo se como va en go, rust, zig, e imagino otros basados en c/cpp/java/c# por extension sera parecido pero con cosas mal hechas por ser lenguajes deprecated. que al final se reducen en compiladores menos potentes, menos eficientes, mas dificiles de escribir, problemas de inferencia.. el tema de tener funciones coloreadas... optimizaciones... problemas al pasarlo por la LLVM

no creo que haya muchas diferencias mas alla de comptime la verdad. aqui si que me pillas porque yo solo he hecho el scheduler no el compilador. y en runtime pues lo mismo... que los tipos sean valores por ejemplo te puede servir... es que es mas dise;o de un lenguaje que no el tema de async en si.

#35407 estoy esperando a un tontito como tu.

que lo explique y haga el ridiculo habitual.

hacerme unos HAHAHAHAHAs

se que no tienes ni puta idea y ahora estas cohibido, por eso me tiras el bait para que te lo explique, pero hoy estoy un nivel por encima de lo habitual.

me he levantado con +150IQ en lugar de los 145IQ habituales.

lo puedo explicar en 4 frases.

#35409 HAHAHAHAHHAHAHAHAHHAHAHAHAHAHAHAHAH

cavando tu propia tumba

10 a;os usando algo que no entiendes

como cuando te pusiste a explicar como funcionaba una cosa del compilador de C# y te puse un video de Anders Hejlsberg explicando como eso funcionaba distinto a lo que decias

#35404desu:

FooController => FooService => FooRepository => FooTable
BarController => BarService => BarRepository => BarTable

que quieres decir con codigo para responder a tu caso de uso? en las aplicaciones fperitas CRUD lo veo bastante util

ense;ame maestro

#35408 Estás deseando que te comamos el culo y te pidamos que lo expliques en 4 frases. Narcicista de manual xDDDD.

Venga porfi porfi porfi porfi porfi porfi porfi

#35421 Esa parte la sé, he trabajado con Reactor en Java y sé usar funciones asíncronas en JS, pero parecía que desu iba a explicar cómo funciona por debajo y cómo se relaciona con el scheduler y tal. Vamos, que sé usarlas pero no sé cómo hacen lo que hacen. Que por cierto es algo que quiero aprender ahora en el paro, así que me viene bien.

#35422 es cuestion de terminologia. si una funcion es una rutina/subrutina, una async es una corrutina.

En el main tienes la stack principal. Y el espacio de memoria alocado para ejecutar una funcion donde pones las variables locales y los parametros es el stack frame. En el stack tienes variables y stack frames de las funciones ejecutándose.

cuando haces return tiras el stackframe del stack del main. pierdes las variables locales de esa funcion.

en las corutinas puedes suspender la ejecucion, devuelves el control a donde estabas pero sin hacer pop. esto es una funcion async.

1 main () {
2   foo()
3 }
4 foo() {
5   suspend 
6 }

para poder volver a esa funcion se usa el famoso "async", que nos devuelve un puntero al stackframe de la corutina. asi desde main puedes volver a donde estabas. Que esto solo es convención, el nombre y lo que devuelve. Puede ser lo que quieras.

1 main () {
2   f = async foo()
3   resume f()
4 }
5 foo() {
6   suspend 
7   return 10
8 }

1. Empiezas cargando el main en LOC 1.
2. En tu stack tienes la linea de ejecucion y las variables del main y los frames...
3. En LOC 2 invocas foo(), y te guardas el puntero al frame.
4. Estas en LOC 6 dentro del stackfram de foo(), ahi haces un suspend y devuelves al ejecucion sin hacer pop del frame.
5. Estas en LOC 3, ahi haces resume del frame.
6. Estas en LOC 7, ahora haces return del 10 y haces pop del frame.
7. Ahora estas en LOC 4, ahi si te hubieses guardado el valor pues lo podrias usar normal... no es mas que otra variable en tu stack.

No hay ningun secreto. Podrias tener una variable global e ir modificandola desde una corutina asi:

1 var global = 0
2 main () {
3   f = foo()
4   while (global != 3) {
5     resume f
6  }
7 foo() {
8   global++
9 }

Luego tienes el keyword await. Que lo que hace es esperar en el main en lugar de seguir la ejecucion... No tiene ningun secreto... en lugar de seguir el codigo espera a que el frame haga return...

Luego porque necesitas que las cosas async vayan con async y hay cosas que no pueden serlo como el main? Pues porque si estas modificando memoria y el codigo se va ejecutando llegara puntos donde estas apuntado a variables no inicializadas, si no haces await y ejecutas el codigo de antes del foo() que devolvia 2 al final. que pasa? pues que te printara lo que sea que tenga en memoria para el stack o puntero. algunas cosas el compilador te las detecta como usar el stack, pero si tienes un puntero no inciializado esperando un valor te printara basura.

Y al final pues como peudes ver solo son punteros para ejecutar las cosas y corutinas. Si tu quieres aqui ejecutarlo en un thread o en otro thread... tener un scheduler inteligente que te haga las cosas o de prioridades... pues haz lo que quieras fpero. Es que el paralelismo no tiene nada que ver con las corutinas XD

La convención de los keywords pues es para que los compiladores detecten fallos. No hay mucho más.

#35425 no es cierto

Ejecutar en otro thead y tener un scheduler no tiene nada que ver.

La corruitna se suspende y puede seguir.
La función hace return.

todos mis ejemplos de arriba son en el mismo thread... no hay ningun scheduler mas alla del OS. y es async...

decir que la diferencia entre una funcion es que se ejecuta en otro thread es mentira. yo puedo ejecutar una FUNCION en otro thread sin problema... no tiene porque ser async... o puedo ejeuctar todo en el mismo ... y el scheduler lo mismo. es que no tiene nada que ver ni existe ninguna correlacion o conclusion o lo que sea que esteis tratando de decir. no tiene sentido ninguno.

hipotesis: la diferencia es que se ejecuta en otro thread
refutacion: una funcion tambien se puede ejecutar en otro thread

voy a subir el 99% al 99.9%. 1 de cada 1000 usuarios de este hilo.

en rust:

fn main() {
    thread::spawn(|| {
            println!("hi from the spawned thread!");
        }
    });
}

vs

fn main() {
    thread::spawn(async || {
            println!("hi from the spawned thread!");
        }
    });
}

no tiene sentido tener una async que no suspende XD pero me da pereza hacer un ejemplo real. se entiende.

Edit: refutación mejor, async también puede ser el mismo thread. XD tiene más sentido como refutación a lo de arriba.

Pero hay mucha gente que cree que async es un nuevo thread siempre y función no. En plan java y go he leído gente así de tontita.