Re: Keep a staff alive with multiple layers (issue 308910043 by address@hidden)

[dak]

On 2016/08/02 11:27:22, dak wrote:
> Personally, I think that this "remove-layer is either a layer number
for
> ourselves or a list of supportive layer numbers who can keep us alive
unless
> this list is empty in which case we can be kept alive by our own
> keep-alive-events" is just a bit too much meaning crammed into one
property.

> I've taken a look a

Sorry, wrong key.  I've taken a look at the code and it does not appear
like there is a danger for infinite loops: the checks for suicide
relying on other axis groups are not called recursively.  The only real
danger we are dealing with here is inefficiency, and particularly
undefined behavior since a context may decide to commit suicide based on
the status of a context which already suicided on the expectation of the
first context staying alive.  If the order of checks in such a situation
are reversed, the outcome may be different.  Should we declare this
"somebody else's problem"?

At the low level, dependencies are decided by make-dead-when and
keep-alive-with properties (containing vertical axis groups) which are
populated based on the remove-layer setting.  If we want to provide the
underlying flexibility, we'd likely need a remove-layer property and
_two_ properties carrying lists of layer numbers.  Or _one_ property
with a list where the _sign_ of the layers indicates friend or foe.

However, using the sign will _fix_ layer numbers to be numbers.  When
going general like that, going via key-list? seems plausible, and then
we'll require two additional lists anyway since a symbol cannot provide
a sign.

So would it make sense to provide the full hog that the low-level
decision engine supports?  Basically, we want the kind of user interface
where people need to think the least but still can do everything they
want to.

https://codereview.appspot.com/308910043/