Fix: Compatibility with Qiskit's run_circuits and CircuitSampler utilities.
#19
Conversation
dbanty
force-pushed
the
fix/compatibility-with-circuit-sampler
branch
from
662577d
to
8226f49
Compare
|
|
||
| if self._status == JobStatus.RUNNING: | ||
| # Wait for results _now_ to finish running, otherwise consuming code might wait forever. | ||
| self.result() |
There was a problem hiding this comment.
So this effectively ensures that status always returns DONE.... I'm wondering if there is something else in the Qiskit Sampler we can hook into to make sure the job actually starts.
I'll spend a bit of time looking and if I don't find anything I'll approve.
There was a problem hiding this comment.
Well it ensures that status always returns DONE or ERROR, depending.
The right way to fix this is the make status polling truly asynchronous so that results can be processed in the order they complete, not necessarily the order they were submitted. But that will require either complicated thread management or a QCS endpoint for checking status quickly.
|
Opened #20 so thoughts about better performance & semantics are indicated somewhere for the future. Will merge this one as-is to get the fix out. |
|
🎉 This PR is included in version 0.4.4 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Some Qiskit utilities (like those mentioned above) will not call
result()unlessstatus()is alreadyDONE. This change makesstatus()immediately block on reading buffers from the QCS backend. Otherwise, those utilities loop forever as we don't have anything polling results asynchronously.As a future performance improvement, we could try a threadpool to check on results and update statuses as we get them (to avoid blocking the main thread), or we could add a result-fetcher in pyQuil which does not wait to reduce the main-thread blocking.