#function-pointers
Posts
-
Digging into MariaDB's Source 9: Execution and the Handler API — How the Nested-Loop Join Calls the Engine
We follow, in the source, the place where the optimizer's plan actually reads rows. From JOIN::exec() into the nested loop of do_select(), sub_select() and evaluate_join_record(), through the read functions chosen for each EXPLAIN type and the join buffer, past the handler's ha_ wrappers, and down to ha_innobase::rnd_next() and write_row(). We count calls with the Handler_read_* status variables, confirm the whole path from do_command to the engine with one gdb backtrace, and see that switching the engine to MEMORY, Aria or BLACKHOLE still goes through the same spots.
-
Digging into nginx's Source 5: Modules and Directives — How One Line of nginx.conf Becomes a Module's Config Struct
An nginx module is a single ngx_module_t struct, and a directive is one row in the ngx_command_t table that struct points to. We follow the module array configure generates, dynamic modules read with load_module, ngx_conf_handler() finding a function by directive name, ngx_http_block() creating per-module config structs for every http, server and location, and the merge that finishes once, at config time. We build a dynamic module with four directives to watch the callback order, the merged values and the error messages.
-
Digging into Apache httpd's Source 2: Before Reading a Server Written in C — Structs, Function Pointers, Macros
Where does the saying "C structs are more beautiful than C++ or Java objects" come from? Without classes or interfaces, how does httpd plug modules in? We check it against the real source and real runs — memory layout with nothing hidden, interfaces built from function pointers, a void * array indexed by module_index, hook functions stamped out by macros, the MMN check that lets httpd trust a separately compiled .so — and the things C will not do for you.