#43162 Ah no tengo ni idea la verdad de eso de auth requestcache a que te refieres.. Con antes te refieres al modelo 1 thread : 1 request? O memoria compartida vs pasar mensajes?
Es que el caso de caching con thread local no lo resuelves entre kernel threads... sigues necesitando compartir una referencia.
https://tokio.rs/tokio/tutorial/shared-state
use tokio::net::TcpListener;
use std::collections::HashMap;
use std::sync::{Arc, Mutex};
#[tokio::main]
async fn main() {
let listener = TcpListener::bind("127.0.0.1:6379").await.unwrap();
println!("Listening");
let db = Arc::new(Mutex::new(HashMap::new())); // *1
loop {
let (socket, _) = listener.accept().await.unwrap();
// Clone the handle to the hash map.
let db = db.clone(); // esto nos da una nueva referencia para pasarlo hacia abajo
println!("Accepted");
tokio::spawn(async move { // *2
process(socket, db).await;
});
}
}
*1 db seria la memoria compartida, en este caso un hashmap que se esconde debajo de un atomic reference count pointer y un mutex
2 fijate en el move, este move mueve la referencia al stack de la corutina** de esta manera te olvidas a nivel de corutina de el thread local de padre... para ti todo esta en tu stack y al terminar te limpias liberando memoria. y el arc hace que rust te gestione el drop por ti.
en este ejemplo tokio::spawn usa el event loop por defecto, que creo que usara tu numero de CPU como numero de threads. para ti el kernel thread es transparente.
que es lo que yo defiendo mas arriba. a mi me gustaria tener tansolo 1 kernel thread por proceso. porque si solo paso memoria a las corutinas y esto lo haces bien, te la suda la memoria compartida... si necesitas comunicar corutinas que serian HTTP request... que cojones estas haciendo?
en que casos de uso necesitas comunicar corutinas entre ellas? mmm muy raro eh. y si necesitas algo compartido, seria atraves del kernel como el ejemplo de la db, y seria a nivel de 1 thread! simplificando todo.
asique tiraria el codigo de arriba con un runtime fijado a 1 kernel thread. y si quiero tener 4 procesos, dentro del contenedor mismo ejecutaria los 4 procesos. si nuuunca algo peta, el contenedor que haga restart del proceso.
el problema que queremos solucionar es tener que gestionar todo el tema de threading y event loops a nivel de aplicacion. porque esto es spring+netty+webflux+reactor y ESTA ROTO, ESTA LLENO DE BUGS.
es que si vosotros haceis un ps aux en vuestra maquina y mirais todo lo que estais corriendo... y mirais los pids y parents... vereis que la manera en que se programa en user space suele diferir del kernel en este sentido... mmm para que quieres tener una jerarquia padre => hijos si son procesos independientes?
si yo tengo un servidor http y tengo 4 cpus, pues tiro 4 procesos, y si uno pasa algo lo reinicio... porque quiero tener 1 proceso, que spawnea 4 threads que tengo YO que contorlar??? no es mas facil que lo haga el kernel por mi?
no se, cual es el pro/cons de tener 1 proceso y tirar 4 threads vs tener 4 procesos de 1 thread cada uno? yo veo mas facil lo segundo XD
