Closed Tectu closed 2 years ago
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 5874a5ac847f9cba1a1dd475fda79268e76cd2ac 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?
@Tectu 5874a5a has a subtle bug
Uh-oh - what did I screw up?
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.
I think that is a good approach.
@0x00002a A typical consuming application of
malloy::server
would usestart()
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 returnedrun_result_t
object to go out of scope which will automatically shut down themalloy::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 therun_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 likestd::optional<run_result_t>
to control the state of themalloy
server?