In a system with multiple sinks, the default sink may not always be
the once currently being used. It is more useful to control the
currently active sink rather than an unused one.
This patch does not make any difference if the system only uses the
default sink.
Signed-off-by: Roosembert Palacios <roosemberth@posteo.ch>
The changes in GCC 11.x made `std::condition_variable` implementation
internals `noexcept`. `noexcept` is known to interact particularly bad
with `pthread_cancel`, i.e. `__cxxabiv1::__force_unwind` passing through
the `noexcept` call stack frame causes a `std::terminate` call and
immediate termination of the program
Digging through the GCC ML archives[1] lead me to the idea of patching
this with a few pthread_setcancelstate's. As bad as the solution is, it
seems to be the best we can do within C++17 limits and without major
rework.
[1]: https://gcc.gnu.org/legacy-ml/gcc/2017-08/msg00156.html
Whenever the network module is configured with both "format" and
"format-$state" and when the module use "format-$state" once, it
override the value that was saved from "format".
For example, if both "format" and "format-disconnect" are configured,
and only those, as soon as the module show information about a
disconnected interface, it will keep showing the format for
disconnected, even if the interface is connected again later.
Fix that by always setting a value to default_format_ in update() and
thus use the intended default format when needed.
Fixes#1129
When an interface's state is change to "down", all the route
associated with it are deleted without an RTM_DELROUTE event.
So when this happen, reset the module to start looking for a new
external interface / default route.
Fixes#1117
The check to figure out if we have the default route should be after
the for loop that parses the route attributes, to avoid acting on
incomplete information. We are going to use more fields from the
message.
The module doesn't update the `essid_` as soon as a WiFi interface is
connected, but that happens at some point later, depending on
"interval" configuration.
Fix that by rerunning the get WiFi information thread when the
`carrier` state changes. Also, we will clear the state related to WiFi
when the connection is drop to avoid stale information.
