mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-04-05 05:30:36 +02:00
d8a31794c8
An asynchronous request should either be cancellable or not keep
the target object alive. Preferably both.
Otherwise, it is impossible to do a controlled shutdown when terminating
NetworkManager. Currently, when NetworkManager is about to terminate,
it just quits the mainloop and essentially leaks everything. That is a
bug. If we ever want to fix that, every asynchronous request must be
cancellable in a controlled way (or it must not prevent objects from
getting disposed, where disposing the object automatically cancels the
callback).
Rework the asynchronous request for connectivity check to
- return a handle that can be used to cancel the operation.
Cancelling is optional. The caller may choose to ignore the handle
because the asynchronous operation does not keep the target object
alive. That means, it is still possible to shutdown, by everybody
giving up their reference to the target object. In which case the
callback will be invoked during dispose() of the target object.
- also, the callback will always be invoked exactly once, and never
synchronously from within the asynchronous start call. But during
cancel(), the callback is invoked synchronously from within cancel().
Note that it's only allowed to cancel an action at most once, and
never after the callback is invoked (also not from within the callback
itself).
- also, NMConnectivity already supports a fake handler, in case
connectivity check is disabled via configuration. Hence, reuse
the same code paths also when compiling without --enable-concheck.
That means, instead of having #if WITH_CONCHECK at various callers,
move them into NMConnectivity. The downside is, that if you build
without concheck, there is a small overhead compared to before. The
upside is, we reuse the same code paths when compiling with or without
concheck.
- also, the patch synchronizes the connecitivty states. For example,
previously `nmcli networking connectivity check` would schedule
requests in parallel, and return the accumulated result of the individual
requests.
However, the global connectivity state of the manager might have have
been the same as the answer to the explicit connecitivity check,
because while the answer for the manual check is waiting for all
pending checks to complete, the global connectivity state could
already change. That is just wrong. There are not multiple global
connectivity states at the same time, there is just one. A manual
connectivity check should have the meaning of ensure that the global
state is up to date, but it still should return the global
connectivity state -- not the answers for several connectivity checks
issued in parallel.
This is related to commit
|
||
|---|---|---|
| .. | ||
| adsl | ||
| bluetooth | ||
| ovs | ||
| team | ||
| tests | ||
| wifi | ||
| wwan | ||
| meson.build | ||
| nm-arping-manager.c | ||
| nm-arping-manager.h | ||
| nm-device-bond.c | ||
| nm-device-bond.h | ||
| nm-device-bridge.c | ||
| nm-device-bridge.h | ||
| nm-device-dummy.c | ||
| nm-device-dummy.h | ||
| nm-device-ethernet-utils.c | ||
| nm-device-ethernet-utils.h | ||
| nm-device-ethernet.c | ||
| nm-device-ethernet.h | ||
| nm-device-factory.c | ||
| nm-device-factory.h | ||
| nm-device-generic.c | ||
| nm-device-generic.h | ||
| nm-device-infiniband.c | ||
| nm-device-infiniband.h | ||
| nm-device-ip-tunnel.c | ||
| nm-device-ip-tunnel.h | ||
| nm-device-logging.h | ||
| nm-device-macsec.c | ||
| nm-device-macsec.h | ||
| nm-device-macvlan.c | ||
| nm-device-macvlan.h | ||
| nm-device-ppp.c | ||
| nm-device-ppp.h | ||
| nm-device-private.h | ||
| nm-device-tun.c | ||
| nm-device-tun.h | ||
| nm-device-veth.c | ||
| nm-device-veth.h | ||
| nm-device-vlan.c | ||
| nm-device-vlan.h | ||
| nm-device-vxlan.c | ||
| nm-device-vxlan.h | ||
| nm-device.c | ||
| nm-device.h | ||
| nm-lldp-listener.c | ||
| nm-lldp-listener.h | ||