What to say...

Well, despite my complete and thorough lack of readership I find myself once again compelled to update, and at least keep the 2-post-per-month average.

I've been doing a bunch of python work for this this weekend. I'm not much for IDEs, or vPython (which is what you code in physics lab at NCSU) but its being written by a friend and when I see code that needs fixing, I have to dig in. Plus Red Hat uses a lot of python around the house, so its nice to have an opportunity to sharpen it.

Brad is a bit of a source of pride for me and my roommate. He moved into my roommate's previous room a few years ago, a former high school football player with a gallon jar of protein supplements and an encyclopedic knowledge of controlled substances (and the rather ugly ways in which they tend to kill people). He's now a full time Fedora user and is solving one of his own problems with a fairly non-trivial python program. We do this to people :)

My other project is a rewrite of prcsys for Fedora. Fedora's boot time has been getting some negative attention lately, so I thought I'd pitch in.

prcsys is a program that boots a folder full of LSB-compliant init scripts in parallel, while respecting any marked dependencies between them. It works somewhat like /etc/rc. We'd like to be able to use it to do job control via DBUS as well. The problem with this is that the current implementation takes a whole folder and starts everything. DBUS would want to probe single files. What complicates this is that prcsys works by starting a thread for every init script and then telling the threads that have dependencies to block on the threads for the scripts that they depend on. It seems fairly smart when you first look at it (though the implementation is a bit strange), but it creates way too many threads if the boot process is mostly linear, and way WAY too many threads if you're intending to start 1 service and maybe 3-ish dependencies.

The replacement, thus, will resolve dependencies by queue. The dependencies are listed by the "Provides" header inside the file and not the filename, so we have to open and read everything in init.d to resolve a single service. That would have been a lot of pthreads to start, the huge majority of which would simply block and then be killed.

The new algorithm simply starts with a queue containing objects representing all of the init scripts. The operation goes like this:

1. Dequeue a script.


2. Is it in the list of things to run? If not, re-enqueue it and go to start.


3. Are its dependencies running? If not, add them to the list of things to run, and re-enqueue it. Go to start.


4. Run it. Go to start

The algorithm halts when a pass is made where nothing runs. Also, scripts can be discarded at step 2 if the list of things to run did not grow in the previous pass.

Well that was dry and dense as usual. Enjoy!