Async plugin startup #38
Conversation
- add signal handling thread so startup is interuptable
application.cpp
Outdated
| @@ -63,8 +65,19 @@ bfs::path application::get_logging_conf() const { | |||
|
|
|||
| void application::startup() { | |||
| try { | |||
| for (auto plugin : initialized_plugins) | |||
| plugin->startup(); | |||
| auto ioc = io_serv; | |||
There was a problem hiding this comment.
It is a copy of the shared_ptr<io_service> captured in post()
There was a problem hiding this comment.
ah yeah missed that it was a shared_ptr
heifner
force-pushed
the
async-startup
branch
from
58a6689
to
d2f4afa
Compare
- add signal handling thread so startup is interuptable
heifner
force-pushed
the
async-startup
branch
from
d2f4afa
to
90077ed
Compare
application.cpp
Outdated
| plugin->startup(); | ||
| auto ioc = io_serv; | ||
| for (auto plugin : initialized_plugins) { | ||
| // order of execution for single-threaded io_service is order of post |
There was a problem hiding this comment.
What are the odds that one day the io_service will not be single-threaded? Could we write this job in a way that it tail-posts the next job instead of posting all jobs and relying on something that may drift in the future? That way the safety is guaranteed by the implementation of this method and not the environment.
There was a problem hiding this comment.
There is actually no reason not to just post the initialized_plugins startup loop itself. Updated PR.
There was a problem hiding this comment.
As per our discussion. Moved setup of sig handler thread to startup() and move plugin startup calls back to caller thread (main thread).
… async-startup
…caller thread (main thread).
exec()tostartup()so that plugin startups are interruptable.