#thread-pool
Posts
-
Digging into Gradle's Source 9: The Task Graph and the Execution Plan — What, in What Order, How Many at Once
How does the pA in gradle pA become packageApp? What do dependsOn, mustRunAfter, shouldRunAfter and finalizedBy turn into inside the execution plan, and who decides the order? Who picks the next node while the build runs, what exactly do --parallel and --max-workers limit, and how does the Worker API split up the work inside a single task? We answer each question from the source at a fixed commit and from examples we actually ran (whenReady, --dry-run, thread names, jstack).
-
Digging into MariaDB's Source 4: Connections and Threads — One Thread per Connection, and the Thread Pool
We follow the source from the moment mariadbd's main thread accepts a connection with poll() and wraps it in a CONNECT, to the point where it hands it to the scheduler (a bundle of function pointers) chosen by thread_handling. We look at the default one-thread-per-connection mode and its thread cache, the login step that creates the THD and authenticates, and how the thread pool — thread groups, a listener, workers and a timer_thread — detaches idle connections from threads, checking each step with ps, information_schema and gdb, and comparing it with httpd's MPMs and Tomcat's endpoint.