xref: /aosp_15_r20/external/perfetto/src/tracing/README.md (revision 6dbdd20afdafa5e3ca9b8809fa73465d530080dc)

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.