The interface every batch worker implements: what it is, which jobs it takes, and how it runs them. More...
| Header: | #include <IBatchWorker> |
| Since: | 1.0 |
| Inherited By: | help::HelpPdfWorker, OpalChatPdfWorker, and OpalTaskBatchWorker |
A worker names itself (workerId(), workerVersion(), workerTags()) and the job types it supports. canAccept() and the per-job canAcceptJob() let it decline work, for example to serialize jobs that share a resource. A worker is a library user, not a framework plug-in: it opts in to the services it wants (§BOC-1). The one mandatory thing is that a job reports its lifecycle through JobContext.
executionMode() chooses one of two contracts. A Pooled worker, the default, implements run(). It runs on a pool thread that libbatch owns, and it returns a JobOutcome; a failure is a returned JobOutcome::failed, because the project does not use exceptions. The dispatcher applies the threadPriority() the worker declares, and restores it after the job. A SelfManaged worker implements start() instead. That call returns at once on the dispatcher thread, and the worker must later complete or fail the job on the queue itself. If a worker implements neither method, the default fails the job with a message that names the defect.
BatchWorkerRegistry holds workers as raw pointers and does not own them. The owner of a worker can delete it once the unregister call returns, because that call waits for the pooled jobs that still use the worker (§BOC-5d).