You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, because create_http_context and similar return non-lifetimed traits, my implementation of HttpContext has to have a 'static lifetime; all the data it contains has to be valid for the entire life of the program. Which is reasonable.
However, my root parses a bunch of data and configuration and holds onto it. To make that data available inside my HttpContext implementation, I can either copy the entirety of that data into the context, or I can make a reference-counted container that gets cloned into the context.
Obviously, one of those options is better than the other, but I was wondering if it's reasonable to say that a request context will never outlive the root context it originated from. If so, then it would be great to update the RootContext trait to have a lifetime parameter 'a, and require it to return only subcontexts that also have lifetime 'a. That would allow HTTP or stream contexts to have simple non-mutable references to the root context. My understanding is that this should also be backwards-compatible, because all current implementations should return 'static contexts which last strictly longer than any other lifetime 'a.
The text was updated successfully, but these errors were encountered:
haikuginger
changed the title
Non 'static lifetime for non-root contexts
Non-'static lifetime for non-root contexts
Mar 20, 2023
Hi all!
Currently, because
create_http_context
and similar return non-lifetimed traits, my implementation ofHttpContext
has to have a'static
lifetime; all the data it contains has to be valid for the entire life of the program. Which is reasonable.However, my root parses a bunch of data and configuration and holds onto it. To make that data available inside my
HttpContext
implementation, I can either copy the entirety of that data into the context, or I can make a reference-counted container that gets cloned into the context.Obviously, one of those options is better than the other, but I was wondering if it's reasonable to say that a request context will never outlive the root context it originated from. If so, then it would be great to update the
RootContext
trait to have a lifetime parameter'a
, and require it to return only subcontexts that also have lifetime'a
. That would allow HTTP or stream contexts to have simple non-mutable references to the root context. My understanding is that this should also be backwards-compatible, because all current implementations should return'static
contexts which last strictly longer than any other lifetime'a
.The text was updated successfully, but these errors were encountered: