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