Always take a reference to the manager when scheaduling an asynchronous
operations. In fact, all callers want to keep the manager alive as long
as there are operations in progress.
Refactor NMFirewallManager to have consistent semantics about
asynchronous calls.
- the callback is always invoked exactly once, but never
synchronously when starting the operation.
- while cancelling the request, the callback is invoked
synchronously with respect to the cancel operation.
- you can cancel a request once (and once only).
- you cannot cancel the request once the callback is invoked.
- when disposing the object with requests pending, the
callbacks are invoked synchronously.
- Add a callback argument to nm_firewall_manager_remove_from_zone().
Otherwise, the user never knows whether a call is still pending and
cancellable (as complete operations cannot be cancelled).
In fact, it makes no sense trying to cancel a call if you don't care
about when it completes.
- get rid of PENDING_CALL_DUMMY. The dummy callback allows cancellation
any number of times. We want to catch wrong usage by asserting that an
operation is only cancelled once.
- nm_firewall_manager_cancel_call() doesn't need the manager argument.
Either the call-id is valid (and has a valid pointer to the manager),
or there is a bug and it is a dangling pointer.
Give it a proper NMFirewallManager* prefix to make it clear where the type belongs.
Also, we will add a similar callback for nm_firewall_manager_remove_from_zone(),
so reflect that in the name.
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Not invoking a callback when cancelling the operation is counter
intuitive.
Note that NMPolicy refs the device, cancelling the call would leave
the reference hanging. That was not an issue because the call was
never cancelled. But still the behavior of NMFirewallManager is
unexpected.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The directory firewall-manager/ only contained one source and one
header file. Move them to the parent src/ directory.
Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-11-19 12:58:36 +01:00
Renamed from src/firewall-manager/nm-firewall-manager.c (Browse further)
