I wish to take up the opportunity of GSoC for submitting a project. I
can work as tutor for it

mod_rivet can only work with non-threaded MPM (Multi-Processing Module). An attempt to create a threaded module had been made by George Petasis in 2012. George was able to rebuild mod_rivet using CMake on Windows and for what I know he had some initial success, but I haven't heard any news from him since then.

The project will be aimed at attain a prototype module supporting both threaded and non threaded MPMs. For example when running with the prefork MPM I wish mod_rivet to preserve the feature of fast cloning running Tcl interpreters. On the other hand with a threaded MPM the module should be able to start a thread pool and control it (as a reference implementation I'm thinking of mod_perl, as George suggested back in 2012)

Therefore by design the new module should be able to understand what is the running MPM and fit into its architecture. This requirement is also needed because, starting with Apache 2.4, the MPM is chosen at run-time

I envision a solution where MPM dependent code is stored in different
files building different binary libraries sharing the same API and binary interface. They will be dlopened (using the Unix terminology) at run time during module initialization so that their functions can be transparently called by a new mod_rivet core module (much like Apache HTTP server core calls its modules). The goals of the project would be met if the developer can achieve a working module capable of running basic Tcl scripts with both families of MPMs. On this prototype we can develop the future of Rivet

The degree of difficulty is probably to be ranked as easy for a student who is already familiar with threads.

Last but not least: having a GSoC student would be an opportunity to get new people involved in Apache/Tcl.

 -- Massimo

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Reply via email to