Control SD sync/async behaviour with env var on QNX #710
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kheaactua
force-pushed
the
async_sd
branch
2 times, most recently
from
7522cf0
to
9855bca
Compare
This is a change intended for systems like QNX which do not generally
have a service like netlink monitoring the network status that can
easily be tied into. This is not setup to be used/enabled on Linux/Android.
SD will use the new asynchronous behaviour if the env var
VSOMEIP_USE_ASYNCHRONOUS_SD is set. If not set, SD will use a
synchronous behaviour and only wait for the interface if the env var
VSOMEIP_WAIT_FOR_INTERFACE exists. The latter (without waiting) is very
close to the upstream behaviour, the difference being that a callback is
still sent to sd::start() from routing_manager_impl, rather than
executing that code directly in routing_manager_impl.
Notes:
- mutexes
- sd_impl::endpoint_ is now mutex protected
- rm_impl::pending_sd_offers_mutex_ is a recursive mutex, as now it
can be called in its own thread and the new thread in SD
- There is no timeout on the waitfor. The original implementation had a
configurable timeout, however because timing out left us in an error
state anyways, this timeout was removed (raised to
numeric_limits<int>::max() = ~45 days, give or take.)
kheaactua
commented
Aug 19, 2024
| @@ -71,7 +82,7 @@ service_discovery_impl::service_discovery_impl( | |||
| find_debounce_time_(VSOMEIP_SD_DEFAULT_FIND_DEBOUNCE_TIME), | |||
| find_debounce_timer_(_host->get_io()), | |||
| main_phase_timer_(_host->get_io()), | |||
| is_suspended_(false), | |||
| is_suspended_(true), // Start suspended: this is different than upstream as we start before a network interface is available | |||
There was a problem hiding this comment.
This introduced a bug where SD tries to start multicast a second time, leading to an error in the log
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is a change intended for systems like QNX which do not generally have a service like netlink monitoring the network status that can easily be tied into. This is not setup to be used/enabled on Linux/Android.
This allows us to launch and use a routing manager with local UDS communication before remote networking is available which simplifies our startup graph and saves time during startup. This is in contrast to the current version where SD will fail to load if networking is not available at process start - leaving the routing manager in an error state.
I have been using this change for 1-2 years now and it has been very beneficial.
Usage
This behaviour can be enabled by exporting the following environment variables:
This is implemented by modifying the signature of
service_discovery::start()in order to accept a callback send fromrouting_manager_impl.Notes:
sd_impl::endpoint_is now mutex protectedrm_impl::pending_sd_offers_mutex_is a recursive mutex, as now it can be called in its own thread and the new thread in SDwaitfor. The original implementation had a configurable timeout, however because timing out left us in an error state anyways, this timeout was removed (raised tonumeric_limits<int>::max()= ~45 days, give or take.)