You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 22, 2023. It is now read-only.
Since some platforms we are going to target in the future will employ cooperative multitasking we have to proof the termination of event handlers.
Currently we need to ensure that an event handler does not return until all work is done as it might not be called anymore otherwise.
Both properties cannot be proven at the same time since the last one includes cases where data arrives fast enough that the event handler will never reach the state to be finished..
The intended solution is to create an (arbitrary) upper limit for all procedures (that can possibly be used to detect progress) for their generated progress. The procedure will then signal that no progress can be made anymore and will cause the event handler to return. If more progress is available it will be handled in the next call of the event handler.
To protect deadlocks due to unhandled data the platform is responsible to check if data is available and call the event handler as long as this is true. Or to employ a busy loop and simply call all event handlers. The latter option is easier to implement but not recommended on platforms that are bound in electrical power.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Since some platforms we are going to target in the future will employ cooperative multitasking we have to proof the termination of event handlers.
Currently we need to ensure that an event handler does not return until all work is done as it might not be called anymore otherwise.
Both properties cannot be proven at the same time since the last one includes cases where data arrives fast enough that the event handler will never reach the state to be finished..
The intended solution is to create an (arbitrary) upper limit for all procedures (that can possibly be used to detect progress) for their generated progress. The procedure will then signal that no progress can be made anymore and will cause the event handler to return. If more progress is available it will be handled in the next call of the event handler.
To protect deadlocks due to unhandled data the platform is responsible to check if data is available and call the event handler as long as this is true. Or to employ a busy loop and simply call all event handlers. The latter option is easier to implement but not recommended on platforms that are bound in electrical power.
The text was updated successfully, but these errors were encountered: