change/extend how execution timeouts work

[ewinston]

This issue is meant to start a discussion about how execution timeouts work.

Currently, the timeout setting of a job starts the clock as soon as a job is submitted. If the job times out, the SDK stops waiting for the result but does not remove the job from the remote queue (this is not currently possible with the API). It may be better to add a timeout, or change the timeout, such that it starts when the circuits in the qobj start executing.

update 12/2018: With asynchronous jobs and the ability to cancel jobs there is less of a need to change how timeouts work, however there is still a use case. A user could want to limit the time taken for a job to run on the backend which might be desirable if the backend charges the user for longer running jobs. Some queuing systems such as LSF support setting a run time limit.

[jaygambetta]

Erick. I agree now that 0.5 is done and we are still using wait and timeout in job.results let’s make this clearer and also give some documentation on how it works.

[delapuente]

Jobs have landed successfully and cancellation will be possible in 0.6 (#638 and #687) so I think this is a good time to re-evaluate this. In my opinion, timeouts are a way of limiting client execution and should not automatically remove a job from a server queue. That does not mean we can have other ways of limiting that time too (probably also called "timeout").

[1ucian0]

@ewinston @jaygambetta @delapuente Any consensus or update?

[jaygambetta]

@ewinston what are you thinking here.

[ewinston]

I updated the description above.

[jaygambetta]

@ewinston i see what you are proposing. Could you put close this issue and make a new one with some pseudo code.

[diego-plan9]

@ewinston can we consider this an IBMQProvider-only issue?

[jaygambetta]

im going to close this as this is really a provider question now.