stop_request.hpp File Reference

Asking a long computation to stop, from outside it. More...

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes
class	bertini::ScopedStopRequest
	Clears any stale stop request on the way in, and again on the way out. More...

Namespaces
namespace	bertini

Functions
void	bertini::RequestStop ()
	Ask any running computation in this process to stop at its next check.
void	bertini::ClearStopRequest ()
	Withdraw a stop request, so later computations run normally.
bool	bertini::StopRequested ()
	Has somebody asked this process to stop?

Detailed Description

Asking a long computation to stop, from outside it.

A solve can run for hours over thousands of paths, and there was no way to tell it to stop. In an interactive session that is worse than slow: pressing Ctrl-C sets a flag CPython raises from its evaluation loop, and the evaluation loop is not running, because the calling thread is down inside the solve. The only exit was killing the process.

The mechanism here is deliberately small: one process-wide flag that anybody may set and that long-running code reads between units of work. Path tracking checks it between steps (see bertini::tracking::Tracker::TrackPath) and reports SuccessCode::ExternallyTerminated, a value that has been in the enum, unproduced, since long before this file.

Process-wide is the right scope, not per-solve. A keyboard interrupt is a fact about the process, not about one object; if two solves are running in threads, Ctrl-C means stop both.

Whoever sets the flag owns clearing it. A flag left set would stop the next computation before its first step, so the setter should use ScopedStopRequest or clear it by hand. The Python bindings install a signal handler for the duration of a solve and do exactly that.

This is cooperative. Nothing is killed, no exception crosses a thread; the computation notices, unwinds the way it always does, and leaves its partial results intact and inspectable. Work already completed stays completed, and – since a solve records each path as it finishes – re-running the same ask recalls what was done and tracks only the rest.