Collection of definitions for modifying channel behaviour.
More...
#include <ChannelDef.hxx>
|
| enum | EntryTimeAspect { Continuous
, Events
, AnyTimeAspect
} |
| | Enumeration type defining the entry data type. More...
|
| |
| enum | EntryArity { OnlyOneEntry
, ZeroOrOneEntries
, ZeroOrMoreEntries
, OneOrMoreEntries
} |
| | Enumeration type defining the arity of the entry. More...
|
| |
| enum | ReadingMode { ReadAllData
, ReadReservation
, JumpToMatchTime
, AdaptEventStream
} |
| | Reading mode, all data, step-by-step or time based. More...
|
| |
| enum | PackingMode { MixedPacking
, OnlyFullPacking
} |
| | Allow differential packing, or always use full packing. More...
|
| |
| enum | TransportClass { UndefinedTransport
, Bulk
, Regular
, HighPriority
} |
| | Different priorities of transporting data. More...
|
| |
Collection of definitions for modifying channel behaviour.
◆ EntryTimeAspect
Enumeration type defining the entry data type.
| Enumerator |
|---|
| Continuous | Stream-like data, time is contiguous.
|
| Events | Event-like data, time is a point stamp, multiple events may share the same time.
|
| AnyTimeAspect | For reading, indicate that both variants are acceptable.
|
◆ EntryArity
Enumeration type defining the arity of the entry.
| Enumerator |
|---|
| OnlyOneEntry | For writing, only one entry may be present in the channel, for reading, attach only a single entry with the token.
|
| ZeroOrOneEntries | When opening the channel for reading, it is acceptable that there is no entry yet.
The token will be valid, but data reading will result in an exception.
|
| ZeroOrMoreEntries | When opening the channel for reading, it is acceptable that there is no entry yet.
The token will be valid, but data reading will result in an exception.
|
| OneOrMoreEntries | Accept one or multiple entries in the channel, relevant option for both reading and writing tokens.
|
◆ ReadingMode
Reading mode, all data, step-by-step or time based.
| Enumerator |
|---|
| ReadAllData | Sequentially read all data, from oldest to newest, all data is read once, and reading fails when no more new data is available for the requested time.
Note that if you select this reading mode, data will be kept in the channel until it is read by your module; thus there is an obligation to read or flush data, otherwise excessive memory use follows.
|
| ReadReservation | Sequentially read all data, from oldest to newest, like ReadAllData.
In addition, this uses a reservation that needs to have been made by the write token(s) that are accessed, ensuring that data written before the creation of this read token remains available. For most user-created channels this is seldom needed, since creation of both reading and writing tokens takes place first, and writing and reading only starts after all tokens have been created. Some of DUECA's own channels do use this, since these channels are created at start-up, and almost immediately used.
|
| JumpToMatchTime | Read data that matches the requested time, possibly skipping data.
To get a workable simulation, specify a suitable time span, otherwise data has been cleaned before you have an opportunity to read it.
|
| AdaptEventStream | Adapt to event or stream data, by using ReadAllData for event type data, and JumpToMatchTime for stream data.
|
◆ PackingMode
Allow differential packing, or always use full packing.
| Enumerator |
|---|
| MixedPacking | Use full and differential packing in a mix.
Select this when you have a mix of static data and changing elements in large objects. With differential packing, an object in a channel is compared to the preceding object, and only elements that differ are packed.
|
| OnlyFullPacking | Only use full packing.
This is more appropriate for channel entries with small object, or when you expect that all or most data changes from timestep to timestep.
|
◆ TransportClass
Different priorities of transporting data.
| Enumerator |
|---|
| UndefinedTransport | Transport class not (yet) specified.
|
| Bulk | Bulk priority is lowest priority in DUECA transport.
Very large objects can be sent by bulk, because in principle the objects do not need to fit in a single buffer used by the transport device. Send and arrival order of Bulk data among its class is preserved, bulk data may arrive later than non-bulk data sent at a later time.
|
| Regular | Regular priority data is sent at the earliest possible moment.
Triggering of arrival at the next node is no later than the first following communication clock tick. Send/receive ordering among high priority and regular data is preserved.
|
| HighPriority | High priority data is sent at earliest possible moment, (like regular data).
However, triggering in the next node is immediately after arrival in that node. The difference between regular and high priority is currently only possible in set-ups with reflective memory communications.
|
The documentation for this struct was generated from the following file: