[Gbbopen-list] KSA retriggering and queue order

[Dan Corkill]

All,  I'm moving this exchange onto the GBBopen List...

Zack wrote:

> Two ksas, say A and B, are added to the agenda.  They both have the same
> priority but, because A came in before B, A is ahead of B.  Then, at
> some point later, both ksas get retriggered and both of their priorities
> are changed to the same new [different] rating.  The order in which the ksas are
> processed determines which ksa will be first in the agenda.  That is,
> whichever ksa is processed first will be first on the agenda.  In
> looking at the code, it looks like the the order is dependent on the
> order of the retrigger list on the ks-triggers (from which the KSs are
> retrieved) and on the order of the pending-activations list of each KS. 
> It doesn't look like either of those lists are ordered much less ordered
> to parallel the agenda, so it seems that the order of the ksas can be
> changed, e.g., B can come before A.
> 
> I can easily imagine you saying that it is not reasonable to expect that
> the initial order would be retained over a double retriggering.

The order or KS triggering/retriggering/obviation from the same event
instance is not "defined" (promised/controllable) in the GBBopen Agenda
Shell.  Unlike event functions, there is presently no "priority" for
ordering the KSA processing associated with the events (and this
wouldn't help you out anyway, as the order you want is based on the
inverse order of the pending KSAs queue).  The pending KSA queue rating
is not designed to provide such fine-grained control/maintenance of
rerating ties.

However, here is a suggestion (untried, and off the top of my head).
You could replace the pending KSAs queue with one of your own that has a
specialized comparison function that breaks ties in the way that you
wish.  It is undocumented, but you can call start-control-shell with a
keyword argument that creates the pending KSAs queue when the Agenda
Shell is initialized.  The default is:

>  :pending-ksas (make-queue :class 'ordered-queue
>                                             :test (if fifo-queue-ordering
>                                                       #'>
>                                                       #'>=)
>                                             :key #'rating-of)

You could provide a different :test function to the queue that, when two
KSA ratings are equal, adds whatever tie-breaking is needed.  In your
case, it might be the original time the KSAs were created (or the time
of the messages that triggered your KSAs, etc.).  This makes the added
"ordering" criteria explicit and adds very little overhead (only looking
at the extra criteria when the ratings of two KSAs are the same).

If you do try this, let us all know how it works out.

-- Dan


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.