Serve Multi-hilo
http_serve_mt lanza N hilos worker que toman conexiones de un canal compartido. Esto alcanza 73K req/s en un ARM64 de 4 núcleos — comparable con net/http de Go.
Código
// nyx-serve multi-threaded — http_serve_mt for 73K req/s
// nyx-serve multi-hilo — http_serve_mt alcanza 73K req/s
import "std/http"
fn on_request(req: Array) -> String {
let method: String = req[1]
let path: String = req[2]
if path == "/" {
return http_response(200, "Hello from worker thread!")
}
if path == "/health" {
return http_response(200, "{\"status\":\"ok\"}")
}
return http_response(404, "not found")
}
fn main() -> int {
// http_serve_mt spawns N worker threads.
// A channel distributes accepted connections to workers.
// Workers parse requests and call the handler in parallel.
let port: int = 8080
let workers: int = 8 // typically: number of CPU cores
print("multi-threaded server on :" + int_to_string(port))
print("worker threads: " + int_to_string(workers))
print("benchmark: 73K req/s on 4-core ARM64")
// Blocks forever, accepting and dispatching connections
http_serve_mt(port, workers, on_request)
return 0
}Salida
multi-threaded server on :8080 worker threads: 8 benchmark: 73K req/s on 4-core ARM64
Explicación
Los loops de accept de un solo hilo llegan rápido a un techo: el kernel puede repartir conexiones más rápido de lo que una goroutine puede parsearlas. http_serve_mt resuelve esto con el clásico patrón productor-consumidor — un hilo de accept alimenta un canal acotado, N hilos worker lo drenan. Cada worker tiene su propio estado de parser, así que no hay contención en el camino crítico. En un ARM64 de 4 núcleos con 8 workers, Nyx alcanza 73K req/s en respuestas HTTP simples — eso está en la misma liga que net/http de Go y muy por delante de Node.js. El GC es consciente de los hilos (GC_THREADS), así que las asignaciones dentro de los handlers son seguras sin sincronización manual.