Lumiera
0.pre.03
»edit your freedom«
|
Go to the source code of this file.
A term of the activity language describing interconnected scheduler activities.
The activity::Term is created as a transient object in builder notation, and used to lay out the specifics of the planned operations necessary to calculate a single frame or to carry out some administrative task. The actual Activity verbs are allocated independently, within the BlockFlow allocation scheme, while the Term links and configures these data records and prepares them to instruct the Scheduler. Through the activity::Term, relevant attachment points are exposed for configuration, yet after posting the entrance point of an activity chain to the Scheduler, the term is obsoleted and can be discarded without affecting the individual Activities awaiting activation through the Scheduler.
The »mechanics« of render activities are considered finite, and cohesive low-level code. Thus only a limited selection of wiring schemes is provided, offering just enough leeway to implement the foreseeable variations in functionality. The underlying operational sequence is as follows
WORKSTART
happens in »management mode«, which is performed single threaded and may alter the scheduler queue (enqueue, dequeue).GATE
can enforce the deadline and block until a predetermined number of prerequisite notifications has been receivedWORKSTART
and WORKSTOP
FEED
records to hold parametersNOTIFY
can be appended and linked to the GATE
of a follow-up job, which thereby becomes dependent on this actual job's completion.While the regular media computation job employs this complete scheme, the Template::META_JOB uses the minimal setup, comprised only of post and invocation (since the meta job is used for planning further jobs and thus entirely in »management mode« and without further inhibitions or notifications). Another variation is presented by the Template::LOAD_JOB, which enables the integration of asynchronous IO. The actual JobFunctor in this case is assumed just to dispatch a long running external IO operation and then return quickly. Upon completion of the external work, a callback will be activated, which must be wired such as to re-activate the rest of the activities. Consequently for this mode of operation the activity chain becomes severed into two segments, cutting right behind the last FEED
-Activity (i.e. after issuing the Job) but before the WORKSTOP
. The callback then dispatches the WORKSTOP
and possibly a chained NOTIFY
.
Definition in file activity-term.hpp.
#include "vault/gear/activity.hpp"
#include "vault/gear/block-flow.hpp"
#include "vault/gear/job.h"
#include "lib/time/timevalue.hpp"
#include <string>
#include <utility>
Classes | |
class | Term |
A Term of the »Activity Language«, describing the steps necessary to perform the calculation of a single frame or similar tasks. More... | |
Namespaces | |
vault | |
Vault-Layer implementation namespace root. | |
vault::gear | |
Active working gear and plumbing. | |