shawn.t.rutledge at gmail.com
Tue Oct 23 21:36:32 BST 2007
On 10/23/07, Jan Claeys <lists at janc.be> wrote:
> Op maandag 22-10-2007 om 21:48 uur [tijdzone +0100], schreef Scott James
> > The parser is a string one; so it could be faster by being binary ...
> > but it wouldn't actually buy you anything; you'd have to re-parse the
> > text files on boot to make sure they hadn't been changed while the
> > computer was off.
> Storing the last file modification time inside the "binary blob" might
> be good enough?
> (Although I'm not sure this will gain a lot of speed, compared to
> disadvantages of the relative opaqueness of a binary format?)
Yeah I thought of that too... if checking the time of the script to
compare it to the blob's update time involves a bunch of seeks, there
is probably not much to be gained. (Depends on the fs implementation
But if the format was one binary blob in the first place, and you had
a special editor for modifying it, there is no room for sync problems.
For example there are generic binary data structures that resemble
XML (self-describing, capable of storing any arbitrary tree-structured
data, with several datatypes available beyond just strings). There
could be an editor app which allows you to modify the tree (an ncurses
version and maybe a graphical one later). But even if the tree is in
binary it still has to be interpreted... it's not directly executable.
You could also think of it as if the scripts are the source code and
they have to be compiled. (Maybe even really compiled into machine
code! Or at least into some sort of pcode that is fast to interpret.)
You don't usually worry about somebody modifying the source to some
program and getting into inconsistent state because they forgot to
compile... it's just understood that is a necessary step. And that
step of doing the compilation is like a "transaction" - it either
succeeds or fails. So if somebody messes up a script they are still
going to get the "last known good" state on the next reboot, because
the compilation failed and the last blob was not overwritten.
More information about the upstart-devel