On Wed, Jun 10, 1998 at 07:57:18PM -0700, Robert Woodcock wrote: > Parallelized booting. What this means is we run multiple bootup scripts > simultaneously. It's a *lot* faster on mid-to-higher-end machines, even > with just one CPU - it'd be wickedly fast with SMP. > > "Hey wait a second that won't work!!! What if the netstd_nfs script runs > before the netbase script is done processing?" > > Well, you're right, but I have another (slightly more original) idea that > will make it work. Boot-time dependancies.
Parallelized booting is a good idea (I'm almost certain that _most_ of my bootup time, and almost ALL of my shutdown time, is spent waiting for tasks to decide they're ready) but boot-time dependencies are way too much work. What's wrong with priority levels? Programs start up in alphabetical order. I wish they would die in reverse-alphabetical order (then we could have S99xdm and K99kdm, which would make the file-rc package look nicer) but priority levels do exactly what you want -- they express boot-time dependencies. We can achieve a huge degree of parallelism simply by running all boot scripts of each priority level in parallel. That is, run all scripts at level 01 (and wait to finish), then run all scripts at level 02, and so on. To see why this should be "parallel enough," look at the large number of scripts running at the default level 20. Also, the only guarantee we've ever made is that scripts are executed in priority order, so running all scripts at level 20 simultaneously shouldn't cause a problem. The hardest thing would be keeping the log messages from getting tangled up. That shouldn't really be too hard for a C/C++ program to do. I've done something almost appropriate in my wvdial package (see class WvLog and WvLogRcv). If enough people dare me, I bet I could whip something like this up (using the existing priority scheme) in an hour or two. Have fun, Avery P.S. why isn't file-rc the standard? It's _so_ much better! And why can't we kill things in reverse alphabetical order? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
