OnixS C++ Fenics UST BIMP Market Data Handler  1.1.0
API documentation
Setting Up Feed Engine

The Feed Engine abstractions encapsulate data receiving aspects to let the handler focus on market data processing. It also provides advanced services for using system resources to achieve the best performance and latency characteristics.

Using the Feed Engine

The Feed Engine logic pushes received market data to the linked Handler instances.

The OnixS::FenicsUST::MarketData::Bimp::SocketFeedEngine is the default implementation of the Feed Engine for receiving live network data. It uses standard socket API.

The following code sample shows how to construct an instance of the Feed Engine, link it with the handler instance, and run the Feed Engine logic to let the handler process incoming market data and other events.

// STEP 1: is to construct a shared feed engine.
SocketFeedEngine feedEngine;
// STEP 2: is to bind feed engine to Handler instances.

The SDK offers the OnixS::FenicsUST::MarketData::Bimp::FeedEngineThreadPool service that cyclically invokes the OnixS::FenicsUST::MarketData::Bimp::FeedEngine::process method of the associated OnixS::FenicsUST::MarketData::Bimp::FeedEngine instance from a set of threads. This service manages a thread pool. When a class instance is created, it creates working threads.

All events exposed by the service are encapsulated into the OnixS::FenicsUST::MarketData::Bimp::FeedEngineThreadPoolListener class. Subscribing to events is done during the service construction.

Feed Engine Events

All Feed engine events are encapsulated into OnixS::FenicsUST::MarketData::Bimp::FeedEngineThreadPoolListener class interface. OnixS::FenicsUST::MarketData::Bimp::FeedEngineThreadPool class accepts instance of listener upon construction.

The following table uncovers Feed Engine events:

Event> Description

It is invoked by Feed Engine Pool's working thread before entering master processing loop.

Event callback is invoked in context of working thread allowing a subscriber to perform thread-specific turning like setting affinity or priority for the thread.


It is invoked by Feed Engine Pool when a working thread is about to end.

Event callback is invoked in context of working thread allowing subscriber to perform thread-specific cleanup like deleting data stored in thread local storage.


It is invoked by Feed Engine Pool when a working thread is idle.

At an active phase, Feed Engine working thread is running market data processing loop. A working thread may wait for incoming market data using appropriate I/O operation.

Event callback also exposes parameter-variable whose value represents time interval working thread is suggested to spend sleeping to reduce races between working threads for executing pending tasks (data reception, data processing, etc.) and thus reduce load onto CPU. Value of parameter can be modified inside the callback body.

It's not recommended to change sleep time interval when working thread entered idle state after waiting for incoming data to avoid overflow of a buffer used for incoming data.
There's no predictability in firing given event by Feed Engine. Each working thread may wait for incoming data or receive incoming data or process data previously received by that or any other threads. Availability of active tasks to be executed by working threads depends on many factors including a number of Handler instances bound, system capacity, a number of allocated working threads, clock resolution and other factors.