6.4 - Managing Connection Threads

The VR-Link simulation drivers create a DtVrlinkConnection, which runs in its own thread.

Each active connection has its own thread of execution. VR-Forces provides a number of mechanisms for marshalling data between the main thread and any connection threads that may exist.

Distributed Objects

Distributed objects are objects whose interfaces can exist in a connection thread (or master display engine) while an implementation of that object exists locally on each display engine to which is it distributed.

Distributed objects can be distributed to just the master display engine or to all display engines. Dcgen is used to define the API (all void functions) of a distributed object. It can then generate an Object Agent definition which is used as the interface to the distributed object. Calls to the agent's methods are relayed to the remote objects and executed by them. (See exampleDistributedObject .)

Shared Settings Objects

Shared Settings objects are mutex-protected blocks of settings data. They may be wrapped by a manager that uses an event signaler (see Event Signals) to signal (to connections) that settings have changed, or they may use the event signaler directly. These are typically used as one way (display engine to connection) data transfers, but there is nothing stopping a connection from grabbing a write lock and making changes. However, there is no built-in mechanism for the display engine to find out that those changes have been made.

Event Signals

Event Signals are sent from the main thread, and can be received in the main thread or any connection. Event Signals are often used by a shared settings manager or shared settings object to tell the connection thread to check because something has changed in a shared settings object. These event signals are often wrapped in a singleton SharedSettingsSignaler. Event Signals are also used to request changes in element attribute values.

Element Data

Certain information about elements is always passed from the connection thread to the main thread. For every entity and interaction that gets processed, an elementID is assigned to it, and a few data fields associated with it are made available, including ID, parent ID (vertices of of multipoint objects are children of the line or area), and type (Entity, Terrain, Prop, Aggregate, and so on). In addition to these fixed data, element attributes may optionally be added to the element data. The types of element attributes may depend on the element type; many elements have display name attributes, entity elements have a damage state attribute, and so on. The full list of supported element attributes is in DtElementAttributes.h. It is easy for developers to extend these.

Element data changes are reported to the connection, and each conection tick, any changes in element data are propagated to the main thread, where all the element data is maintained (in the master display engine's DtDataBank member). Signals are raised in the main thread when element data changes in the DtDataBank.

Elements are usually created by a driver (VR-LinkDriver (entities, aggregates), SceneDriver (props, terrain), InputDriver (Observers) and so the drivers are expected to maintain and report changes in element attributes. If some other object wishes to change element attributes, it can send an event signal to request the change. DtDataBankSignaler provides event signals to request changes in element attributes, which are then effected by the owners of the elements (the drivers) or by the elements themselves.

SimData

SimData is used to provide simulation-specific data (usually VR-Link information), on request, from the connection to a requesting display engine. It currently supports EntityState and FireInteractionState. (VR-Forces maintains much more data than the basic VR-Vantage state data.)Given an element ID (see Element Data), SimData for that element can be requested to be sent, either once or at some periodic update rate. When simData arrives, a boost signal is raised that the requestor can connect to. (See exampleSimData.)

queueSimulationFunction

queueSimulationFunction() is a method in the DtVrlinkDriver that allows you to make a request from the main thread that a function be executed in the connection thread. The arguments to the function are passed across the thread boundary safely, providing another mechanism to get data from the main thread to the connection thread. For example, VR-Forces uses this to push observer information to the connection thread for publishing the observer. Since an accessory has access to the connection and the VR-Link driver, it is an ideal place to set these up.

Accessories

Connections are created and started by a DtVrlinkDriver. There will be a VR-Link driver instance associated with each connection. VR-Forces supports accessory objects that are associated with a driver type. When a driver starts, it looks through the lists of existing accessories and if one supports its type, it 'installs' the accessory into itself. This general mechanism can be used to do a lot of custom connection initialization. The accesory can connect to the signals that the VR-Link driver raises when it starts and stops a connection, get access to the connection, and register creators and instances on the connection object.

Some of the factories (like the visualizer factory) are copied from the main thread to the connection thread when a connection is created. If you have a new type of visualizer (see the exampleBulletHole example) you can register the creator with the main thread and it will get copied to the connection when the connection is created. However, if you want to override a visualizer type that the connection itself might override (with a VR-Link specific version, perhaps), then you must get the creator registered AFTER the connection has registered any connection-specific visualizer creators.

[<< Adding Functionality to a Driver (Accessories)] [Home] [Top of Page]