[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Cron-bug] Entry Storage

From: Ryan M. Golbeck
Subject: [Cron-bug] Entry Storage
Date: Fri, 26 Oct 2001 18:59:34 -0400
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1


        I'll explain my views on the link list thing we semi-talked
about on IRC.

        I have nothing against using a linked list here, in this case
it's probably optimal.  My qualms are about how we use them.  First, I
think there should be a limit on the number of entries in memory at
any one time.  For a large system there could be a lot of job entries,
and storing ones in memory always that run once a month is kind of

        My problem is more of how to store the actual data *within* an
entry.  Now, the command line, the environment, uid, etc are easy
choices. But storing the rest of the time information isn't.  This is
because we need to represent ranges, lists, stepping, asterisks and
such for this entries.

        So there's a couple ways to go about this..  We could just
store them in strings and having matching routines.  This is probably
one of the simplest methods, but least optimal.  We could separate
the lists and such into separate entries, but this is a waste of
space, and it makes it more difficult to weed out entries that might
be removed between wake-ups.  This is also not efficient when we are
checking for matches.  But if we store each user's and system entries
separately in memory, as opposed to one big linked list, it would be
much easier to handle removing entries that have been separated
because of ranges.

        Another option of storing the ranges and lists is in some sort
of bitstring.  This makes it much more efficient to match and also
saves space; just gotta decide on how to set the values.

      The thing I was thinking about for large systems and having a
lot of jobs that are maybe only run once a month is only keeping say
only entries that are going to run today in memory.  The more I think
about this though it doesn't seem like such a good idea because there
is a lot of potiental computation that could have to be done at every

Ryan Golbeck <address@hidden>
Computer Science
University Of Waterloo

GPG: 1024D/78916B84 
1B1B 2A87 3F00 A7FB 40F3  526D 36CF BA44 7891 6B84

reply via email to

[Prev in Thread] Current Thread [Next in Thread]