[Evolution] Wombat termination issues

[Federico Mena Quintero <federico helixcode com>]

Dudes,

I am making some fixes to the PCS and PAS so that they can let Wombat
know when it can terminate cleanly.  My approach is as follows.

PASBook and Cal are the Wombat-side structures for clients.  A
PASBackend or a CalBackend can own several of these client structures,
respectively.  When all the clients disconnect from a backend, the
backend has no reason to keep running, so we terminate it.

The termination of a backend is done as follows.  When it notices that
it has no more clients connected to it, it emits a "last_client_gone"
signal.  Its parent PASBookFactory or CalFactory object catches this
signal and unrefs the backend, thus terminating it.

When either of the singleton factories loses all the backends it
launched, it emits a "last_addressbook_gone" or "last_calendar_gone"
signal, respectively.  The Wombat process then catches this, and if
both the PCS and the PAS factories have zero backends, then Wombat
terminates[1].

The "last_client_gone" signal in backends is new.  They cannot simply
commit suicide by unref()ing themselves because a) this is messy and
is the equivalent of pulling the rug under the factories, and b) the
factories do need to query some stuff from the backends before they
really die.  So the sequence is

        1. The backend loses all clients.

        2. Backend emits the "last_client_gone" signal.

        3. Factory catches the signal.

        4. Factory asks the backend for its unique ID, i.e. its URI.
           The factory looks up the backend in its hash table, removes
           it, and destroys the backend.

        5. If the factory has no more running backends, it emits the
           "last_addressbook_gone" or "last_calendar_gone" signal.

        6. Wombat catches the signal.  It queries both the PCS and the
           PAS factory objects for the number of backends they are
           running; if they both return zero, then Wombat
           terminates[1].

(4) requires the factory to be able to query the backend for its URI.
PASBackend did not provide such a method, so I added it.  CalBackend
did provide it, so it has no problems with this.  I of course also
added the "last_client_gone" signal to both classes.

Chris had suggested using some sort of shared reference count on a
toplevel "Wombat" object; factories would ref and unref this object as
backends were added or removed.  I think using signals is more
flexible and cleaner, though.

I'm testing this patch; I'm very confident about the calendar side of
things, but I'll send a patch against the addressbook since it is not
my code.

Does anyone think I may have overlooked something?

[1] Wombat does not terminate immediately if both factories lose all
their backends.  Instead, termination is done in a timeout handler.
It is done like that because of the infamous race condition in GOAD;
it does not atomically ref() factory objects when they are launched.
This timeout of course does not completely fix the race condition, but
it makes it much less likely to happen.

  Federico