Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[IE PYTHON] wait for infer callback to complete #7374
[IE PYTHON] wait for infer callback to complete #7374
Changes from all commits
ba2a45d
fa5798a
809bb8a
159e8e1
03f643d
da642cd
f79d649
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks strange from API level perspective. User calls wait with wait mode ==
RESULT_READY
, but receivesRESULT_NOT_READY
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am curious about it, why we get
RESULT_NOT_READY
? I understand the idea behind it is to capture status inside callback which will be equal toRESULT_NOT_READY
, and only after returning to python we can obtainOK
. However this could render previous callbacks' "policy" absolutely obsolete. The behavior was even present around March of the current year:openvino/inference-engine/ie_bridges/python/sample/classification_sample_async/classification_sample_async.py
Lines 24 to 29 in 6478f17
I totally understand an idea to be able to call wait inside callback itself. However why we are still passing "the same" status code as a parameter? To my knowledge this
statusCode
would be equal toOK
as cpp implementation marks it this way as we are able to enter a callback and not to confuse users with different names of callback's exit codes. The parameter is here:openvino/inference-engine/ie_bridges/python/tests/test_InferRequest.py
Line 341 in 809bb8a
This needs a follow-up (in my opinion) as it requires:
@nkogteva @akuporos what are your views on that?
@AlexeyLebedev1 could you elaborate more on this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jiwaszki From my point of view, we can't disallow the user to call wait inside callback and vice versa we should not force to do it just to check the status code. I agree that it is strange if status codes received in these two ways would be different. At least it should be documented.
But anyway the behavior should be aligned with C++. cc @ilya-lavrenov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main point of these changes that InferRequest.wait(RESULT_READY) must block the thread until infer_callback function completes, as in c++ api. When we call wait inside callback with no-wait status, we get RESULT_NOT_READY, also like in c++ api and it can confuse user, i agree, but if we want to wait for infer_callback maybe it makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more note: as far as I know user can access output blobs inside callback like in demo pipeline. Thus it makes sense to provide the correct status code which informs of present state - which is
OK
. @ilya-lavrenov is it possible to obtain results in C++ API's callbacks as well? If yes, we should consider changes to C++ API to returnOK
in callback or some new status that is clearer about output blobs status instead of focusing on InferRequest's "life".If we are going to align code to C++ without any changes then it should be properly documented and reflected on the python side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How i knew from @ilya-lavrenov , c++ api supposses that callback is the last stage of inference, that's why
InferRequest.wait(0)
inside callback returns RESULT_NOT_READY. I don't see why we should worry about this status codeopenvino/inference-engine/ie_bridges/python/tests/test_InferRequest.py
Line 341 in f79d649
openvino/inference-engine/ie_bridges/python/tests/test_InferRequest.py
Line 340 in f79d649
openvino/inference-engine/ie_bridges/python/src/openvino/inference_engine/ie_api_impl.cpp
Lines 538 to 545 in f79d649