Pre-flight
Problem or motivation
contracts/jobs.py defines a complete vocabulary for background work JobSpec, JobSnapshot, JobManager, ProgressSink, ProgressEvent, CancellationToken, ThreadCancellationToken, SingleForegroundJobPolicy and OperatorApp.__init__ instantiates self.jobs = JobManager(spec.job_policy) but this is yet to be rendered or read by groundskeeping - this remains a downstream consumer functionality for now
Proposed solution
groundworkers runs three background operations from its setup page
self.run_worker(verify, thread=True, exclusive=True)
# ... then self.app.call_from_thread(finish, result, context)
Other than this, the configuration elements don't extend outside of groundskeeping's contracts
for now, exclusive=True is re-implementing SingleForegroundJobPolicy inline, at each of the three call sites
What we need:
-
An executor. Something that takes a JobSpec and a callable, starts it on a Textual worker, threads the ThreadCancellationToken in, forwards ProgressEvents to JobManager.update, and calls complete on exit. Most naturally reached from PageContext, which today exposes surface, notify, open_wizard and navigation but still need to specify how to actually run the work
-
A job surface. JobManager.active / foreground are computed and never displayed. An indicator in the workbench showing the running job and offering cancel where JobSpec.cancellable is set would make the manager observable.
n.b. ThreadCancellationToken is cooperative (requested / raise_if_requested), so it cannot interrupt a blocked socket or a running query
Alternatives considered
No response
Pre-flight
Problem or motivation
contracts/jobs.pydefines a complete vocabulary for background workJobSpec,JobSnapshot,JobManager,ProgressSink,ProgressEvent,CancellationToken,ThreadCancellationToken,SingleForegroundJobPolicyandOperatorApp.__init__instantiatesself.jobs = JobManager(spec.job_policy)but this is yet to be rendered or read by groundskeeping - this remains a downstream consumer functionality for nowProposed solution
groundworkers runs three background operations from its setup page
Other than this, the configuration elements don't extend outside of groundskeeping's contracts
for now,
exclusive=Trueis re-implementingSingleForegroundJobPolicyinline, at each of the three call sitesWhat we need:
An executor. Something that takes a
JobSpecand a callable, starts it on a Textual worker, threads theThreadCancellationTokenin, forwardsProgressEvents toJobManager.update, and callscompleteon exit. Most naturally reached fromPageContext, which today exposessurface,notify,open_wizardand navigation but still need to specify how to actually run the workA job surface.
JobManager.active/foregroundare computed and never displayed. An indicator in the workbench showing the running job and offering cancel whereJobSpec.cancellableis set would make the manager observable.n.b.
ThreadCancellationTokenis cooperative (requested/raise_if_requested), so it cannot interrupt a blocked socket or a running queryAlternatives considered
No response