Add check_deadline function. #38
Conversation
…uch as reaction_t and self_base_t which, which are defined in reactor.h. Thus, if we put check_deadline inside util.c, it creates mutual dependency between util and reactor.
Thanks for the comments, Soroush. I hope I got your comments correctly in c97abe5. |
| bool _lf_check_deadline(self_base_t* self) { | ||
| reaction_t* reaction = self->executing_reaction; | ||
| if (get_physical_time() > get_logical_time() + reaction->deadline) { | ||
| reaction->deadline_violation_handler(self); |
There was a problem hiding this comment.
@edwardalee The deadline violation handler function is called here. Is this semantically okay?
Because of the way check_deadline() is supposed to work, the deadline handler could be called multiple times (if the caller doesn't terminate the reaction (e.g., by using return) upon check_deadline() returning true, and calls check_deadline() again later). What if the deadline handler had some side effect, including changing a state variable and setting to an output port?
This semantic seems a bit strange to me. Depending on the body of the reaction, the deadline violation handler could be called multiple times within the same tag. Even stranger, the number of times the deadline violation handler is called depends on many external factors, like the load on the system.
There was a problem hiding this comment.
Yes, we decided to do it this way to ensure that the deadline violation handler is called as soon as possible. We could alternatively put it on the reaction queue, but then it is possible that other reactions will be invoked first. Also, the main reaction may need to do some cleanup after the deadline violation is detected. I don't think we should delay invocation of the deadline handler until after that cleanup is finished, but if we don't call it here, that is what would happen.
I don't see anything fundamentally wrong with the deadline handler being called multiple times, if that is what the designer decides to do, although I do think this would be a strange choice.
There was a problem hiding this comment.
Okay, got it.
I think the way the API is documented on the website might be important to make sure programmers fully understand the ramifications of using check_deadline.
There was a problem hiding this comment.
I just merged the PR as I believe we reached an agreement. Please let me know if there's any further suggestion, I'll be happy to address that.
…LF programs as well as the AnytimePrime.lf in lf-lang/lingua-franca#960.
See lf-lang/lingua-franca#403 for more information.
Relevant PR: lf-lang/lingua-franca#960