Order of exitCondition functions.

[ptheywood]

Exit conditions are not executed in the order they are added to the model.

This is unintuivite (although not sure why anyone would actually have two which are order dependent..., i'm abusing it for testing purposes)

This should be well documented or changed to preserve order of adding to the model.

i.e.

FLAMEGPU_EXIT_CONDITION(exitCondition_a) {
    printf("a\n");
    return CONTINUE;
}
FLAMEGPU_EXIT_CONDITION(exitCondition_b) {
    printf("b\n");
    return CONTINUE;
}
// ...
model.addExitCondition(exitCondition_b);
model.addExitCondition(exitCondition_a);
// ...

will produce

a
b

I.e. it appears to be order of definition, not order of adding to the model.

Edit it does not appear to always be order of deinition either:

FLAMEGPU_EXIT_CONDITION(exitCondition_testGetStepCounter) {
printf("a\n");
return CONTINUE;
}
FLAMEGPU_EXIT_CONDITION(exitCondition_increase_expectStepCounter) {
printf("b\n");
return CONTINUE
}
// ...
model.addExitCondition(exitCondition_testGetStepCounter);
model.addExitCondition(exitCondition_increase_expectStepCounter);
// ...

b
a

Edit: Currently, regular exit conditions are called prior to any python(maybe RTC?) exit conditions, which would also warrent documentation.

[Robadob]

It's actually undefined order. They're stored in an `unordered_set` or `unordered_map` or something. Logic being, that anything in the same "layer" should be able to run simultaneously. Hence order is irrelevant.

…

On Fri, 15 May 2020 at 13:22, Peter Heywood ***@***.***> wrote: Exit conditions are not executed in the order they are added to the model. This is unintuivite (although not sure why anyone would actually have two which are order dependent..., i'm abusing it for testing purposes) This should be well documented or changed to preserve order of adding to the model. i.e. FLAMEGPU_EXIT_CONDITION(exitCondition_a) { printf("a\n"); return CONTINUE; } FLAMEGPU_EXIT_CONDITION(exitCondition_b) { printf("b\n"); return CONTINUE; } // ... model.addExitCondition(exitCondition_b); model.addExitCondition(exitCondition_a); // ... will produce a b I.e. it appears to be order of definition, not order of adding to the model. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ptheywood]

In which case it needs clearly documenting.

[Robadob]

Happy for you to add layers to init/exit functions if you think it's justified.

[Robadob]

In which case it needs clearly documenting.

Related to issue #268 which also calls for Exit condition documentation (for a different reason).