Expose `run_result_t` publicly
Tectu opened this issue · comments
@0x00002a A typical consuming application of malloy::server would use start() to create a "session" and then destroys it when the server is supposed to be shutdown. In our examples we're currently just relying on the returned run_result_t object to go out of scope which will automatically shut down the malloy::server infrastructure.
Currently, unless I am missing something, there is no way for a consuming application to properly store the run_result_t object as a class member as we're not exposing the run_result_t type publicly.
Is there some caveat I'm currently not aware of or can we expose that type publicly so a consuming application could have a class member like std::optional<run_result_t> to control the state of the malloy server?
We could expose the alias certainly. The actual controller_run_result should stay private tho imo. Also we need to make it movable (as it currently isn't implicitly, since it has a custom dtor), it was an oversight on my part since if we're going to return a resource handle by value we at least need to allow some form of preserving its lifetime for the user.
Making it movable should be a simple case of adding = default to the move ctor and assignment and adding a check in the dtor for if m_io_ctx is nullptr (i.e. its been moved from). Also should add std::movableto the constraint on T in controller_run_result as its stored by value
I've just finished implementing this so I'll open a pr and we can discuss it there? I like the idea of some kind of session naming, but for that I suggest we move more of client::controller into it, since currently it the controller is still used on the client side to make new connections even after its started running (unlike the server which cannot dynamically add routes after its started, at least currently - not sure if we want this?). We could do this in a similar manner to the websocket connection, where certain functions are disabled depending on if its server or client session.
Edit:
@Tectu 5874a5a has a subtle bug, if you move the object before the threads have properly started it will cause a null pointer deref. Shall I still open that pr?
Ah, unfortunate timing. I just closed this and opened #107 :p
Shall we discuss over there?