On Mon, 2006-08-21 at 22:17 +1000, Robert Collins wrote:
I'd like to make the shutdown procedure async as well - allowing things
like swap log writing to use calls elsewhere in the codebase that are
async - like the disk engines.
Makes sense.
Heres my proposed api:
- on EventLoop you can call addShutdownEvent(callback, callbackdata);
- this builds up a vector of pending shutdown callbacks.
- when the event loop detects its time to stop - i.e. because its had
stop() called, or because its gone idle, it invokes the last registered
callback. This has a signature like 'void SHUTDOWNEVENT(callback,
callbackdata);'. The event loop will invoke it with the loop as the
callback data - so when that routine completes, the loop will move onto
the next shutdown event and so on.
- When the last shutdown event returns, the loop will return to the
caller of run().
Sounds reasonable. My first thinking was why not do this with a
broadcast message bus asking the subsystems to prepare for shutdown, but
this simple scheme is easier.
This has a couple of ramifications:
- we'll need to teach various layers like comms that there core can be
shutdown *while* the event loop is still running - but this is
conceptually quite easy IMO.
Yes.
- we'll have a mismatch between some parts of reconfigure and this
approach, for a but - but thats reasonably easy to deal with in the
short term. Long term, if reconfigure becomes async itself it will be
non problematic.
Agreed. Should not be a problem in itself. But getting the clean store
index management async while still allowing the comm loop to run will be
a bit of a challenge...
Regards
Henrik
