RTIO: Add Error-handling for Multishot Items with Blocking Flag

[ubieda]

Description

This PR introduces an option to provide error-handling capabilities to RTIO multi-shot submissions (e.g: sensor streaming). This blocks the on-going submission, giving the client the chance to either un-block (resume as it is) or cancel and start over the IODEVs config/submissions.

This PR includes:

• Code-changes on core RTIO (API + executor) to support the functionality.
• Testcase locking in behavior.
• Default handling to Sensor API on its occurrence.
• Dependent RTIO bug-fix to prevent CQE semaphore bypassing (non-related bug-fix).

Note

Marked as DNM until #93544 lands

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[bjarki-andreasen]

I wonder if it may be simpler for the user to check the result of and manually resubmit the SQE, given I believe an SQE is cancelled if there is an error.

RTIO_SQE_MULTISHOT_BLOCKED effectively dequeues the SQE until the user allows it to be re-enqueued, is this not essentially the same as the SQE being cancelled on error (dequeued), and the user resubmitting the SQE later?

[ubieda]

I wonder if it may be simpler for the user to check the result of and manually resubmit the SQE, given I believe an SQE is cancelled if there is an error.

RTIO_SQE_MULTISHOT_BLOCKED effectively dequeues the SQE until the user allows it to be re-enqueued, is this not essentially the same as the SQE being cancelled on error (dequeued), and the user resubmitting the SQE later?

AFAIK, cancelled items cannot be un-cancelled (as in, re-use the submission), so the client needs to re-create the SQE submission from the top.

However, I see a couple pros of having a separate flag instead of reusing the existing one:

• I see value in keeping the authority of cancelling items to the clients only mainly for troubleshooting purposes.
• I also like that the flag cannot be confused by other one-shot items that have been cancelled (e.g: in a scenario of a single RTIO client working with multiple IODEVs).

At the end of the day, what we want to do is to let the user know a multi-shot failed, and it's on them to handle it in order to recover. I'm game for discussing what's the best way to do it if it's not this one.

[bjarki-andreasen]

I wonder if it may be simpler for the user to check the result of and manually resubmit the SQE, given I believe an SQE is cancelled if there is an error.
RTIO_SQE_MULTISHOT_BLOCKED effectively dequeues the SQE until the user allows it to be re-enqueued, is this not essentially the same as the SQE being cancelled on error (dequeued), and the user resubmitting the SQE later?

AFAIK, cancelled items cannot be un-cancelled (as in, re-use the submission), so the client needs to re-create the SQE submission from the top.

However, I see a couple pros of having a separate flag instead of reusing the existing one:

* I see value in keeping the authority of cancelling items to the clients only mainly for troubleshooting purposes.

* I also like that the flag cannot be confused by other one-shot items that have been cancelled (e.g: in a scenario of a single RTIO client working with multiple IODEVs).

At the end of the day, what we want to do is to let the user know a multi-shot failed, and it's on them to handle it in order to recover. I'm game for discussing what's the best way to do it if it's not this one.

I thought chained SQEs where automatically cancelled if any SQE fails, I would imagine the same behavior for a multishot SQE (basically an infinite SQE chain), maybe this is not the case?

[teburd]

Multi shot is a bit odd here but I’m with Bjarki, if a multi shot fails a failed completion should be the result and it should not be automatically resubmitted is my thinking.