feature(services): Implement start and stop services by list #95
Conversation
danielSanchezQ
left a comment
There was a problem hiding this comment.
We should consider what happens when intializing and stopping in batches. For what I see (its a bit confusing in the diff, will check later in the bran directly), it being sequential if any of the first would fail the other will not even be tried. Not saying it is the wrong behaviour, but we need to document well how does this features work.
| for mut receiver in receivers { | ||
| receiver.await.map_err(|error| { | ||
| let dyn_error: ::overwatch::DynError = Box::new(error); | ||
| ::overwatch::overwatch::Error::from(dyn_error) | ||
| })?; |
There was a problem hiding this comment.
Both starting and stopping are done in a sequential pattern. We could do it completely asynchronous unless there is a reason to do it in order. In this case I think is ok if we want to keep the ordering of starting and stopping for example. But we should document it.
Otherwise all at the same time should be fine as well.
There was a problem hiding this comment.
This is something we briefly addressed (in one of the many threads) in the huge lifecycle PR, because Antonio pointed this out.
The issue is I don't know of a good std way to achieve this, as I get the feeling overwatch-derive tries to be as slim as possible to not force extra dependencies onto users.
Are we okay doing this? E.g.: With futures::join_all
There was a problem hiding this comment.
Lets keep sequential and just add documentation that the order of the start/stop services is up to the caller.
992ef17 to
e8a814d
Compare
e17b2e1 to
dd73769
Compare
dd73769 to
576b348
Compare
danielSanchezQ
left a comment
There was a problem hiding this comment.
Can we add a test for this?
Merges after: #94
Closes: #82