[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: actionsequence suggestion
From: |
Tim Nelson |
Subject: |
Re: actionsequence suggestion |
Date: |
Mon, 10 Jan 2005 17:14:47 +1100 (EST) |
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 :).
:)
--
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne,
Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim.nelson@webalive.biz
http://www.webalive.biz/
- Re: Order of Execution, (continued)
- Re: Order of Execution, Christian Pearce, 2005/01/05
- Re: Order of Execution, Pau Capdevila/Upcnet, 2005/01/05
- Re: Order of Execution, Brendan Strejcek, 2005/01/05
- Re: Order of Execution, Christian Pearce, 2005/01/05
- Actionsequence as a top level section, Chip Seraphine, 2005/01/05
- actionsequence suggestion, Ed Brown, 2005/01/06
- Re: actionsequence suggestion, Mark . Burgess, 2005/01/06
- Re: actionsequence suggestion,
Tim Nelson <=
- Re: actionsequence suggestion, Brendan Strejcek, 2005/01/10
- Re: actionsequence suggestion, Ed Brown, 2005/01/10
- Re: actionsequence suggestion, John Borwick, 2005/01/10
- Re: actionsequence suggestion, Ed Brown, 2005/01/10
- Re: actionsequence suggestion, Tim Nelson, 2005/01/10
- Parrot, cfengine, and embedded languages, David Douthitt, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Mark . Burgess, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Pe5kyTac0, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Christian Pearce, 2005/01/11
- Re: Parrot, cfengine, and embedded languages, Tim Nelson, 2005/01/11