Feda /dev/ - No Javascript allowed

#35435 Las herramientas gráficas te solucionan mucho la papeleta en casos de merges cabrones, cuando tienes que arreglar veintipico conflictos yendo clase por clase y mirando qué línea te quedas y cuál no. Por lo demás, es simplemente hacerlo con un click o con un comando.

#35436 la cuestión está en que si se hacen commits atómicos (que es lo que se debería), seguido del correspondiente git pull, nunca te deberías encontrar en una situación en la que tengas que arreglar veintipico conflictos. Y como comenta el de arriba, para cosas avanzadas, el terminal es mucho más cómodo.

#35439eondev:

No se es algo bastante simple, no hace falta divagar tanto poniendo ejemplos tontos XD

como puedes ver todo el mundo ha respondido mal. incluso tu ahora. aunque la mayoria de gente tiene una intuicion bastante correcta, a nivel de implementacion no entienden como va. como he dicho arriba, la respuesta es funcion return, corutina suspende y resume... no hay mas.

en tu frase tu mismo te lias,

#35439eondev:

o una operación cpu bound si necesita paralelismo

para que quieres una funcino asincrona si es cpu bound? XD quieres una funcion normal... si no vas a suspender pa que queires una corutina? es estupido. lo de necesitar paralelismo no tiene ningun sentido lo que dices.

#35439eondev:

o tirar de asincronia con un sheduler, sin necesidad que tirar del pool de threads.

estas mezclando paralelismo con concurrencia. una funcion async en el main ya es concurrencia. el scheduler sobretodo es para gestionar el paralelismo.... el tema de pool de threads no tiene absolutamente nada que ver con la concurrencia o ser async o no... puedes tener un pool de kernel threads o un pool de user threads...

es una pregunta que me gusta mucho para entrevistas porque me gusta implementar el scheduler en pseudocodigo y hablar de la stack, del stackframe... cuando hice los chat en zig y en rust para paracticar, en zig hice el scheduler a mano, un for loop guarro en un thread nuevo. fin. facilisimo, maximo rendimiento y eficiencia. en rust en cambio necesitas con tokio definir el "scheduler". ya a;ades abstracciones que no controlas y no siempre necesitas..

a nivel de gestion de memoria es muy interesante el tema tambien, aunque es mas bien entender local threads que no async. es un tema que yo mismo me lio cuando hago rust. porque estoy acostumbrado al csp.

#35442desu:

para que quieres una funcino asincrona si es cpu bound

No he dicho eso, vuelve a leerlo. Estoy nombrando todos los casos en los que necesitas X cosas y de qué se compone.

Edit, no he dicho nada, no sabes leer xD

#35426 Si, se puede ejecutar en el mismo thread, de hecho también lo puse, también una fn sync se puede ejecutar en otro thread, si. En realidad vine a decir que casi son lo mismo, que toda la parte de stack punteros y tal es igual que ejecutar una función, la diferencia está en si bloqueas o si suspendes (sales del cpu).

Aunque generalmente, la corutinas se ejecutan en otro thread y las llamadas a funciones en el mismo thread, pero no tiene por qué ser así, ya que no tiene nada que ver una cosa con la otra (threads y async) aunque un poquito si.

Sin embargo con suspend hablas en realidad de blocking/non-blocking, ya que sync significa que una cosa va detrás de la otra y async que una cosa no tiene que esperar a la otra.

#35448 no tiene nada que ver aunque un poquit si XDDD

blocking/non blocking => return o await async para bloquear. una funcion normal el caller siempre espera el return, una funcion async el caller solo esperara el resultado si haces el wait. no tiene nada que ver el suspend ahi para bloquear o no bloquear. es el await lo que importa. porque esperar o no es el caller quien decide.

sync significa que una cosa va detras de otra? no tiene porque. una cosa va detras de la otra porque escribimos los runtime asi, pero yo puedo ejecutar si quiero las cosas en orden aleatorio XD imaginate un main donde cada linea la ejecuto en orden aleatorio. por poder puedo... es sync porque las cosas empiezan y termian y popean el stackframe... por eso son funciones sync. de hecho en un scheduler de corutinas muchas cosas son round robin o random...

async signfiica que una cosa NO tiene que esperar a la otra? no tiene porque. puedes tener codigo async y hacer un await. refutado. la funcion sigue siendo async pero ahora tiene que esperar a otra.

async significa que vas a suspender. fin.

podeis seguir tirandolas, soy muhammad ali

el vocabulario de sync y async ya me parece mal. no se de donde viene. prefiero rutina y corutina. "co" rutina, de "cooperativa". es una rutina cooperativa porque devuelve la ejecucion (suspend).

si el scheduler puede parar la ejecucion desde fuera y dar la CPU a otro seria una rutina preemptiva. si algo de mayor prioridad entra, lo mete.

si no es preemptiva, el scheduler tiene que esperar a que termina la rutina. y mete lo de mayor prioridad.

pero si es una rutina cooperativa, la corutina puede hacer un suspend y devolver el control. por eso se le llama "cooperativa". porque permite que sea preemptiva al scheduler sin que el scheduler la lie. preemptive cooperative scheduling.