feature/udp-receive-thread-timing-configuration

[rex-schilasky]

Description

There was one hardcoded udp sample receive timeout parameter of 10 ms inside CSampleReceiver::Receive. This function is used in 3 different receive threads for registration, logging and payload udp sample receiving. This internal parameter is now replaced by a function parameter and can be configured in ecal_def.h.

/* cylce time udp registration receive thread in ms */
#define CMN_REGISTRATION_RECEIVE_THREAD_CYCLE_TIME_MS  1000

/* cylce time udp logging receive thread in ms */
#define CMN_LOGGING_RECEIVE_THREAD_CYCLE_TIME_MS       1000

/* cylce time udp paylaod receive thread in ms */
#define CMN_PAYLOAD_RECEIVE_THREAD_CYCLE_TIME_MS       1000

They are adapted from 10 ms to 1000 ms. This will not lead to any new functional behavior except the the graceful shutdown of an eCAL node can take up to 1000 ms in theory.

Furthermore, there is a rarely used functionality of the CSubscriber API (CSubscriber::SetTimeout(int timeout_)) to define a timeout for incoming payload messages (independent from the transport layer). The resolution can be configured by the ecal_def.h parameter CMN_DATAREADER_TIMEOUT_RESOLUTION_MS. This parameter is now changed from 10 ms to 100 ms to decrease the cpu load of this test logic.

Summary:

• hard coded receive timeout (10 ms) in CSampleReceiver::Receive replaced by function parameter
• separate udp receive thread cycle time parameter introduced for registration, logging and payload (ecal_def.h), default now 1000 ms
• delta time (resolution) for checking subscriber timeouts increased from 10 ms to 100 ms

Related issues

Related to #1236

Cherry-pick to

• none