Use of Interrupts and ISRs can cause non deterministic behavior during normal execution time. The API should not require that interrupts be used to provide feedback to the application.
Comment 1 Ajay Jayaraj 2016-09-19 06:22:24 PDT
I agree with the intent of this requirement. However, mention of interrupts and ISRs seems to be an implementation detail that is typically not specified in a Khronos API.
May be this could be put under the section 'guidelines' as an advisory point to that not overlooked.
Comment 3 Erik Noreke 2016-09-19 06:57:44 PDT
This would be more of a guideline or recommendation for the implementer rather than the API. It could be worded such that the API should not force an implementer to use interrupts or ISRs as a guideline.
Comment 4 Erik Noreke 2016-09-20 13:07:28 PDT
Setting QA contact to non-member SCAP mailing list.
Comment 5 Daniel Herring 2016-10-02 19:50:57 PDT
Rewording as positive requirement, in place of negative requirement.
Comment 6 Daniel Herring 2016-11-07 07:47:26 PST
The application should not have to specify an interrupt handler, or register callbacks which are executed in an asynchronous manner.
The driver may still use interrupts within the driver implementation but from the application perspective the application should not know of the use of interrupts.
Comment 7 Erik Noreke 2016-11-07 07:48:19 PST
Daniel Herring 2016-09-15 07:27:16 PDT
Use of Interrupts and ISRs can cause non deterministic behavior during normal execution time. The API should not require that interrupts be used to provide feedback to the application.
Comment 1 Ajay Jayaraj 2016-09-19 06:22:24 PDT
I agree with the intent of this requirement. However, mention of interrupts and ISRs seems to be an implementation detail that is typically not specified in a Khronos API.
Comment 2 illya@codeplay.com 2016-09-19 06:39:01 PDT
May be this could be put under the section 'guidelines' as an advisory point to that not overlooked.
Comment 3 Erik Noreke 2016-09-19 06:57:44 PDT
This would be more of a guideline or recommendation for the implementer rather than the API. It could be worded such that the API should not force an implementer to use interrupts or ISRs as a guideline.
Comment 4 Erik Noreke 2016-09-20 13:07:28 PDT
Setting QA contact to non-member SCAP mailing list.
Comment 5 Daniel Herring 2016-10-02 19:50:57 PDT
Rewording as positive requirement, in place of negative requirement.
Comment 6 Daniel Herring 2016-11-07 07:47:26 PST
The application should not have to specify an interrupt handler, or register callbacks which are executed in an asynchronous manner.
The driver may still use interrupts within the driver implementation but from the application perspective the application should not know of the use of interrupts. Comment 7 Erik Noreke 2016-11-07 07:48:19 PST
Accepted per teleconference 2016-11-07.
Daniel to add additional language.