Feature Request: Kill session->run process

[jaredmessenger]

For mobile & embedded devices session->run is typically initiated through a user interaction. If the user presses the back button or continues to another screen before session->run finishes, the process is still lingering in the background wasting resources. Since these devices are relatively low powered, it would be great if we could cancel/kill the process when it's not needed anymore.

[yaroslavvb]

Can you kill the whole process that contains TensorFlow using OS-level tools (ie, sending kill signal)? Interrupting a session.run call without restarting a process was brought up in #11303

[jaredmessenger]

For iOS, I'm not aware of a way to kill a process other than for the end-user to kill the entire app.
The paradigm for long running processes is to subclass NSOperation and periodically check the cancelled property.

class TFSession: NSOperation {
    override func main() {
        if self.cancelled {
            return
        }
        // Do some work
        if self.cancelled {
            return
        }
        // Do more work
        // ...
    }
}

This obviously isn't a good solution since iOS is such a small part of Tensorflow, but what about a cancel_op that a developer can sprinkle throughout their graph? This has a different challenge of accepting a pointer in the feed_dict though.

[tensorflowbutler]

It has been 14 days with no activity and this issue has an assignee.Please update the label and/or status accordingly.

[tensorflowbutler]

It has been 14 days with no activity and this issue has an assignee.Please update the label and/or status accordingly.

[tensorflowbutler]

Nagging Assignee: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

[petewarden]

I'm not sure how this would easily fit into the current TensorFlow Session::Run() architecture, since it seems like it would require at least some modifications to the inner loop of the executor and careful testing to ensure that nothing was left in an inconsistent state during the interrupt. I can definitely see how useful it would be, but for now I'll have to close this as infeasible. Pull requests, or more information about why we should reopen it would be welcome of course!