[Developers] New schedule bin PostPostInitial?

[Erik Schnetter]

On May 25, 2008, at 17:25:08, David Rideout wrote:

> Adding a new schedule bin will solve this problem in the short term,
> however I have some reservations.
> The Cactus 4 scheduler was designed to prevent this very problem -- a
> proliferation of schedule bins.  In Cactus 3, I understand, the number
> of schedule bins increased without bound, with names not so unlike
> this one.  In principle, in Cactus 4, we should be able to get by with
> a single schedule bin, and use before and after to order our routines.
> In practice schedule bins are useful in simplifying the task of
> ordering routines.  I feel that we should think carefully before
> adding another bin.  Is it really necessary?  If so it should have a
> well defined need.  Is your alternate suggestion to do the recursive
> initialization before POSTINITIAL?  This makes more sense to me.  Or,
> if the new bin is really necessary, at least use a name which somehow
> describes the need, as you suggest.

Since Cactus is used in production, each design decision has to be a  
compromise between elegance and performance and backward  
compatibility.  In this case, changing the meaning of POSTINITIAL  
requires changes to many existing thorns.

I think the best action to take is to introduce the new bin now, and  
to restructure the names and meanings of the bins at a later time,  
without time pressure.

> I understand that with Cactus 5 we will have a script based scheduler,
> which will eliminate the need for agreement of the entire developers
> list for such design decisions...


It is already possible to introduce new schedule bins, although they  
are then called "groups" instead.  But it is still necessary for a  
large group of users to agree on the names and meanings, since  
everybody using Carpet or Whisky needs to use and understand them.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20080526/49b979c3/attachment.bin