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::movable
to 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?