| How to use this library | |
| ----------------------- | |
| There are three options to use this library: | |
| ## Option 1) Fully in-process | |
| In this mode Producer, Consumers and the Service are hosted in the same process. | |
| This is not too interesting other than tests and particular cases of nesting | |
| tracing instances coming from different libraries within the same process | |
| (concrete example v8, skia and webrtc in Chrome). | |
| In this configuration, the client is expected to at least: | |
| - Create a TracingService instance via TracingService::CreateInstance | |
| (see `core/tracing_service.h`) | |
| - Subclass Producer (`core/producer.h`) and connect it to the service. | |
| - Provide a TaskRunner implementation (see `test/test_task_runner.h`) | |
| - Provide a trivial SharedMemory implementation (`core/shared_memory.h`) which | |
| is simply backed by a malloc() buffer. | |
| ## Option 2) Using the provided UNIX RPC transport | |
| The `include/unix_rpc` provides the building blocks necessary to implement a RPC | |
| mechanism that allows Producer(s), Consumer(s) and Service to be hosted on | |
| different processes on the same machine and talk over a UNIX domain socket. | |
| - Producer(s) are expected to get a service proxy via | |
| `UnixServiceConnection::ConnectAsProducer()`. | |
| - The `Service` must be instantiated via `UnixServiceHost::CreateInstance()`. The | |
| returned instance encapsulates the `Service` and exposes two UNIX sockets (one | |
| for Producer(s), one for Consumer(s)) on the current process. | |
| ## Option 3) Providing a custom RPC transport | |
| Similar to Option 2, but the client creates its own transport mechanism, | |
| defining how methods are proxies between instances and providing a SharedMemory | |
| implementation that can be transferred through RPC. Concrete example of this is | |
| Chrome implementing this library over a Mojo transport. | |
| Directory layout | |
| ---------------- | |
| `include/` | |
| Is the public API that clients of this library are allowed to depend on. | |
| Headers inside include/ cannot depend on anything else. | |
| `src/` | |
| Is the actual implementation that clients can link but not expected to access | |
| at a source-code level. | |
| **Both have the following sub-structure**: | |
| `{include,src}/core/` | |
| "Core" is the pure c++17 tracing machinery that deals with bookkeeping, | |
| ring-buffering, partitioning and multiplexing but knows nothing about | |
| platform-specific things like implementation of shared memory and RPC mechanism. | |
| `{include,src}/unix_rpc/` | |
| A concrete implementation of the transport layer based on UNIX domain sockets | |
| and posix shared memory. |