Closed
Bug 819060
Opened 12 years ago
Closed 12 years ago
Asynchronous observer mechanism
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
DUPLICATE
of bug 722648
People
(Reporter: Yoric, Unassigned)
References
Details
Until now, we have been happy with a synchronous observer/observer service mechanism. Upon notification of an event:
- each observer is called successively, execution waits until completion of the observer;
- notification returns once all observers have returned.
As we are progressing towards heavily asynchronous code, this is not going to be satisfactory much longer. I believe that we will need an async observer/observer service mechanism. Upon notification of an event:
- each observer is called successively and passed a callback (and possibly an opaque closure object);
- notification returns once all observers have returned;
- notification calls its own callback once all observers have called their callback.
In order to avoid disrupting too much existing code, I suspect that we will want our asynchronous mechanism to also accept regular, synchronous observers, which are automatically uplifted to asynchronous observers.
An immediate application is asynchronous shutdown, in which we need to ensure that all subsystems of a given "ring level" (for the lack of a better term) have completed their shutdown before proceeding to the next "ring level". We might also benefit from such system during initialization.
Comment 1•12 years ago
|
||
dupe of bug 722648?
Reporter | ||
Comment 2•12 years ago
|
||
Good catch.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•