The results from my previous run at making rc startup faster were not so impressive mostly because the rc portion of startup doesn't (normally) take very long.
But ... I'm not going to lie - I had fun doing it. The previous run was successful in that it works and does offer some benefit for very busy systems with lots of services while imposing no penalty for simpler installations. Learning how to trace a sh script during the early phase of startup on a readonly file system was an interesting challenge.
So here's a new idea that should make rc as fast as possible - but still only requires changes to rcorder and /etc/rc.
The original rc order uses a topological sort to determine a safe ordering for all rc scripts. The trouble is rcorder has no idea when any of these scripts actually complete. Providing feedback to rcorder would allow it to better choose alternate rc scripts to run while a long running script has yet to complete. This means having rcorder read from stdin to know when a particular script has completed. An alternative is have rcorder invoke the scripts directly but I don't want to go there. I'd rather have /etc/rc control that.
Each rc background task would read a line of text from the same rcorder. Once the background task is complete, it writes the same line of text back to rcorder, and then reads the next line. You could have "N" background tasks running. All background tasks race to get the next script name. Once rcorder returns EOF, the tasks exit. When rcorder sees the name of an rc script in its stdin, it marks that script as done which implies dependent scripts may be eligible to run. rcorder then prints the next eligible script name to stdout.
My expectation is this won't be much faster than rc or the improved rc that supports rc_task_limit but I can't say for sure without trying.
But ... I'm not going to lie - I had fun doing it. The previous run was successful in that it works and does offer some benefit for very busy systems with lots of services while imposing no penalty for simpler installations. Learning how to trace a sh script during the early phase of startup on a readonly file system was an interesting challenge.
So here's a new idea that should make rc as fast as possible - but still only requires changes to rcorder and /etc/rc.
The original rc order uses a topological sort to determine a safe ordering for all rc scripts. The trouble is rcorder has no idea when any of these scripts actually complete. Providing feedback to rcorder would allow it to better choose alternate rc scripts to run while a long running script has yet to complete. This means having rcorder read from stdin to know when a particular script has completed. An alternative is have rcorder invoke the scripts directly but I don't want to go there. I'd rather have /etc/rc control that.
Each rc background task would read a line of text from the same rcorder. Once the background task is complete, it writes the same line of text back to rcorder, and then reads the next line. You could have "N" background tasks running. All background tasks race to get the next script name. Once rcorder returns EOF, the tasks exit. When rcorder sees the name of an rc script in its stdin, it marks that script as done which implies dependent scripts may be eligible to run. rcorder then prints the next eligible script name to stdout.
My expectation is this won't be much faster than rc or the improved rc that supports rc_task_limit but I can't say for sure without trying.