Closed thynson closed 3 months ago
On second thought, should this be a field of ClientConfig? It's only needed for outgoing connections, after all.
I tried but was stuck with the mutability of the ClientConfig. Maybe some interior mutability pattern should applied here. A mutex is required to do so.
I'll find some time to implement a ClientConfig
version in a couple of days.
On second thought, should this be a field of ClientConfig? It's only needed for outgoing connections, after all.
I tried but was stuck with the mutability of the ClientConfig. ~Maybe some interior mutability pattern should applied here~. A mutex is required to do so.
I'll find some time to implement a
ClientConfig
version in a couple of days.
Not sure what you mean? EndpointConfig
ends up in an Arc
inside Endpoint::config
, too, so how is the mutability of ClientConfig
different/an issue?
On second thought, should this be a field of ClientConfig? It's only needed for outgoing connections, after all.
I tried but was stuck with the mutability of the ClientConfig. ~Maybe some interior mutability pattern should applied here~. A mutex is required to do so. I'll find some time to implement a
ClientConfig
version in a couple of days.Not sure what you mean?
EndpointConfig
ends up in anArc
insideEndpoint::config
, too, so how is the mutability ofClientConfig
different/an issue?
The EndpointConfig
holds an Arc
of a factory, when building an Endpoint
, an instance of Box<dynConnectionIdGenerator>
is obtained from the factory, so the mutability issue is not applied there.
Updated to move it to ClientConfig
Added a commit that replaces ConnectionIdGenerator with function trait instead. It will be squashed if approved.
This PR implements #1896.