Hi I'm in the process of figuring out if mod_rivet could fit into an Apache http server using 'worker' as mpm. Rivet embeds Tcl in Apache and enables server side scripting using the Tcl language in pretty the same style you can do using PHP, for instance.
I don't even know if this is possible as the big PHP itself for long time used to work only with a prefork server (and maybe still does...), but having threads could be a plus on heavily loaded servers and on certain architectures. So here I am... I tried an empiric approach, recompiling both Apache and Rivet with 'worker' as mpm and with debugging symbols, just to see what's going one in a threaded server. I assumed that basically threads would take the role that used to be a child's role with prefork. Instead it seems that threads are managed following a different logic: apparently threads are created when a request comes and their number seems not to be restricted by the parameter ThreadsPerChild (I set it as 2) The module seems to work (it logs data) but eventually it's unable to send data down the connection, most likely because the Tcl interpreter gets spoiled somehow (shouldn't just one thread be running if I have a single request being served?) I'm puzzled. Googling the subject didn't add more to what I already knew, so my questions are: - is the a general paper about the worker mpm as seen from the developer perspective? - Apart the usual caveats of accessing global/shared data after a Mutex lock has been gained, what a module is supposed to do in order to handle threads properly? Nick once said modules must be mpm agnostic as much as possible. Maybe it must be read as "module must be mpm agnostic if they can?" - How a child process can setup a thread environment and its private data? I apologize for the lengthy message. Thank you if you have read it up to the bottom line -- Massimo
