Consider these two calls, in either order:
id1 = virConnectDomainEventRegisterAny(conn, NULL,
VIR_DOMAIN_EVENT_ID_LIFECYCLE,
VIR_DOMAIN_EVENT_CALLBACK(callback), NULL, NULL);
virConnectDomainEventRegister(conn, callback, NULL, NULL);
Right now, the second call fails, because under the hood, the
old-style function registration is tightly coupled to the
new style lifecycle eventID, and the two calls both try
to register the same global eventID callback representation.
We've alreay documented that users should avoid old-style
registration and deregistration, so anyone heeding the advice
won't run into this situation. But it would be even nicer if
we pretend the two interfaces are completely separate, and
disallow any cross-linking. That is, a call to old-style
deregister should never remove a new-style callback even if it
is the same function pointer, and a call to new-style callback
using only callbackIDs obtained legitimately should never
remove an old-style callback (of course, since our callback
IDs are sequential, and there is still coupling under the
hood, you can easily guess the callbackID of an old style
registration and use new-style deregistration to nuke it - but
that starts to be blatantly bad coding on your part rather
than a surprising result on what looks like reasonable
stand-alone API).
With this patch, you can now register a global lifecycle event
handler twice, by using both old and new APIs; if such an event
occurs, your callback will be entered twice. But that is not a
problem in practice, since it is already possible to use the
new API to register both a global and per-domain event handler
using the same function, which will likewise fire your callback
twice for that domain. Duplicates are still prevented when
using the same API with same parameters twice (old-style twice,
new-style global twice, or new-style per-domain with same domain
twice), and things are still bounded (it is not possible to
register a single function pointer more than N+2 times per event
id, where N is the number of domains available on the connection).
Besides, it has always been possible to register as many
separate function pointers on the same event id as desired,
through either old or new style API, where the bound there is
the physical limitation of writing a program with enough
distinct function pointers.
Adding another event registration in the testsuite is sufficient
to cover this, where the test fails without the rest of the patch.
* src/conf/object_event.c (_virObjectEventCallback): Add field.
(virObjectEventCallbackLookup): Add argument.
(virObjectEventCallbackListAddID, virObjectEventStateCallbackID):
Adjust callers.
* tests/objecteventtest.c (testDomainCreateXMLMixed): Enhance test.
Signed-off-by: Eric Blake <eblake@redhat.com>
On the surface, this sequence of API calls should succeed:
id1 = virConnectDomainEventRegisterAny(..., VIR_DOMAIN_EVENT_ID_LIFECYCLE,...);
id2 = virConnectDomainEventRegisterAny(..., VIR_DOMAIN_EVENT_ID_RTC_CHANGE,...);
virConnectDomainEventDeregisterAny(id1);
id1 = virConnectDomainEventRegisterAny(..., VIR_DOMAIN_EVENT_ID_LIFECYCLE,...);
And for test:///default, it does. But for qemu:///system, it fails:
libvirt: XML-RPC error : internal error: domain event 0 already registered
Looking closer, the bug is caused by miscommunication between
the object event engine and the client side of the remote driver.
In our implementation, we set up a single server-side event per
eventID, then the client side replicates that one event to all
callbacks that have been registered client side. To know when
to turn the server side eventID on or off, the client side must
track how many events for the same eventID have been registered.
But while our code was filtering by eventID on event registration,
it did not filter on event deregistration. So the above API calls
resulted in the deregister returning 1 instead of 0, so no RPC
deregister was issued, and the final register detects on the
server side that the server is already handling eventID 0.
Unfortunately, since the problem is only observable on remote
connections, it's not possible to enhance objecteventtest to
expose the semantics using only public API entry points.
* src/conf/object_event.c (virObjectEventCallbackListCount): New
function.
(virObjectEventCallbackListAddID)
(virObjectEventCallbackListRemoveID)
(virObjectEventCallbackListMarkDeleteID): Use it.
Signed-off-by: Eric Blake <eblake@redhat.com>
Tighten up scope after the previous patch avoided using
internals. This will also make it easier to change
internal implementation without having to chase down quite
as many impacted callers or worrying about two files getting
implementations out of sync.
* src/conf/object_event_private.h
(virObjectEventCallbackListAddID, virObjectEventQueueClear)
(virObjectEventStateLock, virObjectEventStateUnlock)
(virObjectEventTimer): Drop prototype.
(_virObjectEventCallbackList, _virObjectEventState)
(_virObjectEventCallback): Move...
* src/conf/object_event.c: ...here.
(virObjectEventCallbackListAddID, virObjectEventQueueClear)
(virObjectEventStateLock, virObjectEventStateUnlock)
(virObjectEventTimer): Mark private.
Signed-off-by: Eric Blake <eblake@redhat.com>
Right now, the older virConnectDomainEventRegister (takes a
function pointer, returns 0 on success) and the newer
virConnectDomainEventRegisterID (takes an eventID, returns a
callbackID) share the underlying implementation (the older
API ends up consuming a callbackID for eventID 0 under the
hood). We implemented that by a lot of copy and pasted
code between object_event.c and domain_event.c, according to
whether we are dealing with a function pointer or an eventID.
However, our copy and paste is not symmetric. Consider this
sequence:
id1 = virConnectDomainEventRegisterAny(conn, dom,
VIR_DOMAIN_EVENT_ID_LIFECYCLE,
VIR_DOMAIN_EVENT_CALLBACK(callback), NULL, NULL);
virConnectDomainEventRegister(conn, callback, NULL, NULL);
virConnectDomainEventDeregister(conn, callback);
virConnectDomainEventDeregsiterAny(conn, id1);
the first three calls would succeed, but the third call ended
up nuking the id1 callbackID (the per-domain new-style handler),
then the fourth call failed with an error about an unknown
callbackID, leaving us with the global handler (old-style) still
live and receiving events. It required another old-style
deregister to clean up the mess. Root cause was that
virDomainEventCallbackList{Remove,MarkDelete} were only
checking for function pointer match, rather than also checking
for whether the registration was global.
Rather than playing with the guts of object_event ourselves
in domain_event, it is nicer to add a mapping function for the
internal callback id, then share common code for event removal.
For now, the function-to-id mapping is used only internally;
I thought about whether a new public API to let a user learn
the callback would be useful, but decided exposing this to the
user is probably a disservice, since we already publicly
document that they should avoid the old style, and since this
patch already demonstrates that older libvirt versions have
weird behavior when mixing old and new styles.
And like all good bug fix patches, I enhanced the testsuite,
validating that the changes in tests/ expose the failure
without the rest of the patch.
* src/conf/object_event.c (virObjectEventCallbackLookup)
(virObjectEventStateCallbackID): New functions.
(virObjectEventCallbackLookup): Use helper function.
* src/conf/object_event_private.h (virObjectEventStateCallbackID):
Declare new function.
* src/conf/domain_event.c (virDomainEventStateRegister)
(virDomainEventStateDeregister): Let common code handle the
complexity.
(virDomainEventCallbackListRemove)
(virDomainEventCallbackListMarkDelete)
(virDomainEventCallbackListAdd): Drop unused functions.
* tests/objecteventtest.c (testDomainCreateXMLMixed): New test.
Signed-off-by: Eric Blake <eblake@redhat.com>
We might as well take advantage of viralloc.h instead of open-coding
array management ourselves. While at it, I simplified several
places that were doing repetitive pointer chasing to use an
intermediate variable for legibility (some other places remain,
but they will disapper in later refactoring patches).
* src/conf/object_event_private.h (_virObjectEventCallbackList):
Use size_t for count.
* src/conf/object_event.c (_virObjectEventQueue): Likewise.
(virObjectEventCallbackListRemoveID): Use VIR_DELETE_ELEMENT.
(virObjectEventQueuePush, virObjectEventCallbackListAddID): Use
VIR_APPEND_ELEMENT.
(virObjectEventCallbackListEventID)
(virObjectEventStateDispatchCallbacks): Simplify code.
Signed-off-by: Eric Blake <eblake@redhat.com>
No need to use an int that only ever stores 0 and 1.
* src/conf/object_event_private.h (_virObjectEventCallback):
Change deleted to bool.
* src/conf/object_event.c (virObjectEventDispatchMatchCallback):
Switch return type to bool.
(virObjectEventCallbackListMarkDeleteID): Update client.
* src/conf/domain_event.c (virDomainEventCallbackListMarkDelete):
Likewise.
Any file with access to object_event_private.h also has access to
the internals of virObjectEvent, without needing an accessor
function. Not to mention the accessor function was doing type
checks that would always succeed.
* src/conf/object_event_private.h (virObjectEventGetEventID): Drop.
* src/conf/object_event.c (virObjectEventGetEventID): Drop.
(virObjectEventDispatchMatchCallback): Simplify caller.
* src/conf/domain_event.c (virDomainEventDispatchDefaultFunc):
Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
While working on events, I found a number of minor issues; I'm
hoisting these to the front rather than doing it piecemeal in
the patches where I first noticed bad or missing documentation.
* src/conf/object_event.c: Fix grammar, document all parameters
of public functions, wrap some long lines.
* src/conf/object_event.h: Likewise.
* src/conf/network_event.c: Likewise.
* src/conf/domain_event.c: Likewise (except for the large number
of event creation functions).
* src/libvirt_private.cyms (conf/object_event.h): Split...
(conf/network_event.h): ...to account for new file.
Signed-off-by: Eric Blake <eblake@redhat.com>
The event namespace concept is mostly redundant information.
With the re-written dispatcher, the namespace is only used
for equality comparisons between event IDs. This can be solved
by just comparing virClassPtr instances instead.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Instead of having the object event code have to know about each
type of event and their dispatch functions, associate a dispatch
function with the object instance. The dispatch code can thus be
significantly simplified.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
While running objecteventtest, it was found that valgrind pointed out the
following memory leak:
==13464== 5 bytes in 1 blocks are definitely lost in loss record 7 of 134
==13464== at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==13464== by 0x341F485E21: strdup (strdup.c:42)
==13464== by 0x4CAE28F: virStrdup (virstring.c:554)
==13464== by 0x4CF3CBE: virObjectEventCallbackListAddID (object_event.c:286)
==13464== by 0x4CF49CA: virObjectEventStateRegisterID (object_event.c:729)
==13464== by 0x4CF73FE: virDomainEventStateRegisterID (domain_event.c:1424)
==13464== by 0x4D7358F: testConnectDomainEventRegisterAny (test_driver.c:6032)
==13464== by 0x4D600C8: virConnectDomainEventRegisterAny (libvirt.c:19128)
==13464== by 0x402409: testDomainStartStopEvent (objecteventtest.c:232)
==13464== by 0x403451: virtTestRun (testutils.c:138)
==13464== by 0x402012: mymain (objecteventtest.c:395)
==13464== by 0x403AF2: virtTestMain (testutils.c:593)
==13464==
Hitting this should be pretty rare, but at least developers will know
that they are providing a weird event ID. Otherwise for namespace that
are added in the normal way, gcc will raise a warning about unhandled
case in the switch.
Define the public API for (de-)registering network events
and the callbacks for receiving lifecycle events. The lifecycle
event includes a 'detail' parameter to match the domain lifecycle
event data, but this is currently unused.
The network events related code goes into its own set of internal
files src/conf/network_event.[ch]
