Open zizhengtai opened 4 years ago
Another way to do this while keeping backwards compatibility is:
Arc
s inside Tera
with Rc
sTera
now to a TeraInner
and Arc
-wrap it inside Tera
:
struct Tera {
inner: Arc<TeraInner>,
}
struct TeraInner { / a bunch of stuff / }
However, I still think externalizing the `Arc` is the most flexible approach.
I do want tests/filters/functions to be Send
though. Would https://github.com/getzola/zola/blob/master/components/templates/src/global_fns/mod.rs (+ rayon) still work without too much overhead?
Would https://github.com/getzola/zola/blob/master/components/templates/src/global_fns/mod.rs (+ rayon) still work without too much overhead?
I'm not sure I follow...?
I'm using
Tera
withactix-web
, which creates a separate app state (including aTera
instance in my case) per thread. I was originally doing something like this:I looked into the struct
Tera
and realized that I'm actually cloning a bunch of stuff (such asHashMap
s andVec
s), so I decided to do this instead:But then I noticed that there are already
Arc
s insideTera
, which I think is wasteful in this case. I could be totally wrong and maybeTera
is designed this way for a reason, but I think it'd be more flexible if we replace theArc
s insideTera
withRc
s. This will have several consequences:Test
,Filter
andFunction
traits will no longer need to beSend
. This should be a backwards-compatible change.Tera
struct will no longer beSend
. We need to wrap it in anArc
if we want to send it between threads.This change will bring the following benefits:
Tera
from multiple threads (which I suppose all server frameworks require) since we don't have doubleArc
s anymore.Tera
from a single thread since we don't needArc
at all.The only downside I can think of is that making
Tera
notSend
is a breaking change. I'd like to hear your opinions.