Re: actionsequence suggestion

[Ed Brown]

"Elegance", like beauty, is definitely in the eye of the beholder.  

Maintaining the suggested linked dependencies might make sense from a
concurrent programming best practices standpoint, but it certainly is
not "elegant" in my aesthetic.  My goal is not optimizing for
performance or parallelization, it is making things easier for myself. 
Linked dependencies means keeping track of different tags for every
relationship; multiple tags/attributes for a given instance of an action
when a chain of dependencies is involved, multiple files to edit to make
changes, the possibility of broken dependencies or chains of
dependencies, and an obfuscation of the actual sequence.  

If it helps you to think, or program, in terms of dependencies rather
than sequence, just consider that a "deptag=25" automatically sets up
dependency relationships with deptags greater and lesser than itself.
Please don't require that I set up both ends of every relationship
explicitly, especially when multiple levels of relationship are
required.  

Also no mention was made of backwards compatibility.  If you do away
with actionsequence altogether, every relationship that you care about
has to be structured, per individual instance of the action, because you
are dealing with per-action attributes.  What a nightmare.  If you do
allow an actionsequence definition, how do you deal with conflicts, ie,
a defined dependency opposite the defined actionsequence. Numeric
priorities handle this easily in that the defined actionsequence only
applies at the same priority level, actually extending flexibility in
scheduling, rather than creating a conflict.

-Ed


 


On Sun, 2005-01-09 at 23:14, Tim Nelson wrote:
> On Thu, 6 Jan 2005 Mark.Burgess@iu.hio.no wrote:
> 
> > Something like this could be done in the future, but I would not do it with
> > classes. I would have priority attributes.  priority=X
> >
> > Thanks for the suggestion
> > I shall have this in mind for cfengine 3
> 
>       Hmm.  The rc.x priorities system has recently been slammed because 
> it is the way it is, instead of using dependencies (which would allow 
> parallel execution, and greatly reduce startup time for Linux boxes). 
> Additionally, a colleague sent me the following this morning
> -------------------------------------
> http://www.gotw.ca/publications/concurrency-ddj.htm
> 
> Executive Summary:
> CPUs are no longer progressing n raw clock speed, and the future is in 
> multicore and multithreaded processors. BUT this means that developers 
> will be required to start thinking seriously about programming for these 
> concurrent systems.
> -------------------------------------
> 
>       When I have problems like this, it's usually because I'm 
> attempting to make things happen in a certain sequence.  I know that 
> cfengine is designed to work non-sequentially, but this is a problem for 
> actions that need to happen in a sequence.
> 
>       So, in my mind, we're trying to come up with a solution that works 
> within the following constraints:
> 1.    Does not encourage sequential thinking (as this is not cfenginely)
> 2.    Allows sequential sequences where necessary
> 3.    Uses something more user-friendly than the current actionsequence
>       solutions to these problems.
> 
>       I personally would like to add the following constraint:
> 4.    Is more elegant than the suggested priority system (which to my
>       mind has the elegance of the old BASIC/ForTran line numbers).
> 
>       My suggestion would be to add *two* attributes:
> 
>       deptag=foo
> 
> ....
> 
>       dependson=foo
> 
>       These would be on two separate actions.  In fact, this type of 
> system could entirely replace the actionsequence, and would greatly 
> enhance parallelisation abilities.  Cfengine would merely need to resolve 
> the dependency tree, and then it would know how to divide tasks between 
> "thread", or whatever it is that we want to do.
> 
>       Hmm.  Definately not until cfengine 3, anyway :).
> 
>       :)