Clarify blocking behavior of queue::submit
#354
Conversation
| <<command-group-function-object>> (as described in | ||
| <<sec:command-groups-exec-order>>) in the calling thread, thereby scheduling a | ||
| <<command-group>> for asynchronous execution. Any error in the submission of a | ||
| <<command-group>> is handled by throwing a synchronous SYCL exceptions. |
There was a problem hiding this comment.
| <<command-group>> is handled by throwing a synchronous SYCL exceptions. | |
| <<command-group>> is handled by throwing a synchronous SYCL exception. |
| <<sec:command-groups-exec-order>>) in the calling thread, thereby scheduling a | ||
| <<command-group>> for asynchronous execution. Any error in the submission of a | ||
| <<command-group>> is handled by throwing a synchronous SYCL exceptions. | ||
| Any exceptions from the <<command-group>> after it has |
There was a problem hiding this comment.
| Any exceptions from the <<command-group>> after it has | |
| Any errors from the <<command-group>> after it has |
I think we mean errors more generally here, right? For example, an error from the underlying backend could cause the asynchronous error handler to be called. An exception from the application's host task could also cause the asynchronous error handler to be called, but we say that in the definition of host tasks.
Notably, exceptions in other commands are not guaranteed to call the asynchronous error handler (because exception are not allowed in device code).
There was a problem hiding this comment.
Right. Not really related to this PR but I guess we can do a drive-by clarification :)
psalz
force-pushed
the
clarify-blocking-queue-submit
branch
from
7758819
to
faf4526
Compare
|
will wait, need more time |
Clarify that the CGF provided to
queue::submitis invoked in the calling thread.Resolves #307.