Scope has to make to make decisions in RC without knowing if the task is next to start

[sirctseb]

This is bad because scope might decide an entity should be killed, but the state could change before the entity would actually start. Or scope could decide another entity should be interrupted for the new one, and we would interrupt, but the new one wouldn't actually start.

We need to either be able to tell if this release condition is the last before a task starts, or be able to enumerate all entities that are scheduled to begin a task and are having their release conditions evaluated, and scope would make a decision for all of them at the same time.

[sirctseb]

The interrupt problem could be solved by recording the strategy info and suspending the interrupted task in BE of the new task

[sirctseb]

Reject might be fixed also by recording the strategy and aborting it during the next BE of another task. But we still don't know if the rejected task would have been the one to start this time. No, I think this is equivalent to the old way. In fact that is exactly what the old way is.

[sirctseb]

Another idea for rejecting: If scope says reject in an RC, mark entity as TO_REJECT or so. Return false for RC, but don't kill it in another BE until the clock exceeds the original schedule start time of the rejected entity. In the mean time, keep evaluating it during its RCs and if it ever comes back true, take off the TO_REJECT mark. This way, the entity doesn't lose its chance to start when the state changes at the same clock time.

Then a question is, is it a problem that an entity isn't rejected until after the time it was supposed to start?

[sirctseb]

For delaying: We could just do the same as above for reject. Problem: We would need to be careful about registering it as a delayed task before any other decisions are made. For example, we can't let any other tasks end before it's registered because there should be a resume decision for it.

Or we could just mark it DELAY and suspend it ASAP, because it won't be lost forever anyway. If a task ends at the same clock time, but after it is suspended, it could just be resumed anyway. Problem: we could have a delay and resume for the same task at the same time. This could be detected and sanitized. Bigger problem: the resume decision is a distinct from release decision, so there is different logic.