| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It can be quite nice to expose a basic set of metrics
about the internals of an engine, including the time
in each state, and how long the engine is active for
and likely more in the future.
To start add a engine statistics property and gather
some basic timing data and place this data into this
property for access (and/or introspection) by users.
Part of blueprint gather-engine-statistics
Change-Id: Ibc3c78755bd8ae779b52fc4772519f243a521576
|
| |
|
|
|
|
|
| |
Some things that popped out while reading the
comments/documentation.
Change-Id: I0ccecae3381447ede44bb855d91f997349be1562
|
| |
|
|
|
|
|
|
|
| |
Instead of creating a throw-away executor and then passing it to the
engine for usage there just pass a string that specifies that we want
the executor created/used to be process based and let the engine handle
the creation and shutdown of that executor on its own.
Change-Id: Ib9cdbe50d1a12ec8b5bec86531f76ef51926645c
|
|
|
In order to support tasks notifications and progress
updates we need to establish a channel & proxy by which
those events can be sent from the process executing and
producing those events and the originating process that
requested that task to be executed.
This review adds on such a proxy and adjusts a cloned tasks
notification callbacks to place messages on a queue that will
be picked up by a thread in the originating process for dispatch
to the original callbacks that were registered with the non-cloned
task (therefore making the original callbacks appear to be called
as they are supposed to be).
Part of blueprint process-executor
Change-Id: I01c83f13186e4be9fa28c32e34e907bb133e8fb3
|
