docs about nesting ServiceLaunchers

[weissi]

Very clearly ServiceLaucher is helpful for the top-level thing in probably main.swift and that's why it has builtin support for handling signals & doing backtraces.

However, the lifecycle concept is much bigger than what you do in main.swift.

Consider the following example:

final class MySystem {
    private let subSys1
    private let subSys2
    private let lifecycle
    init() {
        self.subSys1 = SubSys1()
        self.sybSys2 = SubSys2()
        self.lifecycle.register(name: "sub sys 1", start: self.subSys1.start, shutdown: self.subSys1.shutdown)
        self.lifecycle.register(name: "sub sys 2", start: self.subSys2.start, shutdown: self.subSys2.shutdown)
    }
    func start() {
        self.lifecycle.start() // calls subSys1.start and subSys2.start
    }
    func shutdown() {
        self.lifecycle.shutdown()
    }
}

There, lifecycle is also super useful and I think we should add an example like this to the docs. And the API docs need a big fat warning that catching signals & registering backtraces is only for the top-level ServiceLauncher.

[tomerd]

@weissi this is a great idea, we can def make them compose nicely. to your point on top-level we can potentially compose the type hierarchy differently to make this easier and safer

[weissi]

@tomerd ah you mean a different type for top-level and not? I think I like that. So one would be called ServiceLauncher and one ComponentLifecycle or so?

[tomerd]

@tomerd ah you mean a different type for top-level and not? I think I like that. So one would be called ServiceLauncher and one ComponentLifecycle or so?

exactly, see #15 for a POC

[ktoso]

Yeah I quite like the direction :)

[tomerd]

closed via #34