OnixS C++ CME iLink 3 Binary Order Entry Handler  1.18.2
API Documentation
Threading Models

The handler supports the following threading models for usual sockets:

The OnixS::CME::iLink3::ThreadingModel::External mode supports the Solarflare TCPDirect technology that is described in the Solarflare TCPDirect section.

The model is configured via the OnixS::CME::iLink3::SessionSettings::threadingModel(ThreadingModel::Enum value) method.


In OnixS::CME::iLink3::ThreadingModel::Dedicated mode the Handler creates a dedicated receiving thread and a dedicated sending thread for each OnixS::CME::iLink3::Session instance.

The receiving thread receives and processes incoming SBE messages.

The Handler tries to send an outgoing application-level message in the thread that calls the OnixS::CME::iLink3::Session::send method. If the message cannot be sent immediately, then it is saved to the queue for the subsequent sending by the sending thread. This behavior can be changed using the OnixS::CME::iLink3::Session::messageGrouping method.

The following table shows which thread could fire a particular callback.

CallbackApplication threadHandler's Sending threadHandler's receiving thread
OnixS::CME::iLink3::SessionListener::onError No Yes Yes
OnixS::CME::iLink3::SessionListener::on*(All incoming strongly typed callbacks) No No Yes
OnixS::CME::iLink3::SessionListener::onReceivedBytes No No Yes
OnixS::CME::iLink3::SessionListener::onMessageSending Yes Yes


OnixS::CME::iLink3::SessionListener::onStateChange Yes Yes Yes
OnixS::CME::iLink3::SessionListener::onWarning Yes Yes Yes


In OnixS::CME::iLink3::ThreadingModel::Pool mode the Handler creates the thread pool and shares it between all sessions. The maximum number of threads in the pool is configured via the OnixS::CME::iLink3::SessionSettings::threadPoolSize parameter. The default value (0) of this parameter means that the thread pool's size will be equal to the CPU's number. In the thread pool, each thread performs read/write operations and can process a number of different FIXP connections, which are distributed equally among all threads. The thread pool is used also to perform the asynchronous TCP connect when the OnixS::CME::iLink3::Session::connectAsync() method is called.


In OnixS::CME::iLink3::ThreadingModel::External mode the Handler does not create I/O threads. Such mode means that user creates additional threads himself (or uses the main thread), then performs event dispatching in a loop by calling the OnixS::CME::iLink3::SessionReactor::dispatchEvents() routine. This mode supports the Solarflare's TCPDirect and regular TCP connections. For TCPDirect connections, one should use the OnixS::CME::iLink3::TcpDirectStack as a reactor. For regular TCP connections, one should use OnixS::CME::iLink3::TcpStandardStack as a reactor.

The TCPDirect technology is NOT thread-safe. Therefore, the event dispatching and message sending should be performed from the same thread.
OnixS::CME::iLink3::ThreadingModel::External mode is set automatically when an external reactor is provided to the session's constructor, regardless of which threading model was specified by SessionSettings. If OnixS::CME::iLink3::ThreadingModel::External mode is configured, but an external reactor is not provided during Session's construction, an exception will be thrown.

Additional Threads That Can Be Spawned

If the configured threading model equals OnixS::CME::iLink3::ThreadingModel::Dedicated and the OnixS::CME::iLink3::Session::connectAsync() method is used, the Handler creates a separate thread to perform the asynchronous TCP connect. Each such thread is started when the OnixS::CME::iLink3::Session::connectAsync() method is called and is stopped when the asynchronous TCP connect is completed.

If the OnixS::CME::iLink3::SessionStorageType::AsyncFileBased value is passed to the OnixS::CME::iLink3::Session constructor, the Handler creates an additional thread for each Session instance. This thread performs session storage operations.

When a session has some network issues, the Handler will restore the FIXP connection. For this purpose, a separate thread is created to avoid blocking Handler's IO threads in non-TCPDirect connection modes.