Dynamic rendering mode #324
Conversation
Kijewski
force-pushed
the
pr-dynamic-rendering
branch
3 times, most recently
from
ad08c26 to
edb222b
Compare
|
I started the PR before #255, that's why there is a conflict. Could you have a first cursory look if you like the idea, @GuillaumeGomez? IMHO that could be a killer-feature. :) How to use:
Runtime values most likely won't work, because I don't know how to serialize them. |
|
What's this feature about btw? |
|
Live-updating the templates, one of the most requested unimplemented features in askama: askama-rs/askama-old#491. (Instead of manually compiling, something like |
|
😮 Wow. Ok, let me get through it. |
|
|
||
| use super::{DYNAMIC_ENVIRON_KEY, MainRequest, MainResponse, Outcome}; | ||
|
|
||
| const PROCESSORS: usize = 4; |
There was a problem hiding this comment.
Any reason why four?
There was a problem hiding this comment.
No. :) Maybe the processor count would be better?
There was a problem hiding this comment.
Why do we need multiple processors?
There was a problem hiding this comment.
Without it the templates are rendered one after another.
On my not-so-recent AMD Ryzen 7 2700X system, with four workers and in release mode, the rendering takes about the same time in dynamic mode as non-dynamic: 68µs vs 65µs in he axum example.
There was a problem hiding this comment.
I see, another code comment. :D
|
|
||
| let mut entries: Vec<_> = DYNAMIC_TEMPLATES.iter().map(|entry| entry.name()).collect(); | ||
| entries.sort_unstable(); | ||
| eprintln!("templates implemented by subprocess: {entries:?}"); |
There was a problem hiding this comment.
println! instead maybe? It's not an error after all.
There was a problem hiding this comment.
STDIN & STDOUT are reserved for communication with the parent process.
There was a problem hiding this comment.
Sounds like a code comment is needed. :)
There was a problem hiding this comment.
Yeah, possibly even a small UML'like actor diagram.
| for window in entries.windows(2) { | ||
| if let &[a, b] = window { | ||
| if a == b { | ||
| eprintln!("duplicated dynamic template {a:?}"); |
|
|
||
| let is_done = { | ||
| let mut stdout = stdout.lock().await; | ||
| stdout.write_all(line).await.is_err() || stdout.flush().await.is_err() |
There was a problem hiding this comment.
For it to be done, it needs to return an error? Seems a bit strange. At the very least, a code comment would be appreciated here.
There was a problem hiding this comment.
If the connection to the parent process was interrupted, the child process can exit. Severing the connection is the first step in killing a subprocess.
rinja/Cargo.toml
Outdated
| linkme = { version = "0.3.31", optional = true } | ||
| notify = { version = "8.0.0", optional = true } | ||
| parking_lot = { version = "0.12.3", optional = true, features = ["arc_lock", "send_guard"] } | ||
| tokio = { version = "1.43.0", optional = true, features = ["macros", "io-std", "io-util", "process", "rt", "sync", "time"] } |
There was a problem hiding this comment.
linkmeandnotifyare absolutely needed.- I tried to implement the PR without an
asyncruntime, but well, tokio is just too well implemented to invent the wheel twice. parking_lotcould maybe be replace with anstd::sync::Barrierof some sort. It's far from trivial, though.
|
I think I'll need more technical explanations. From what I can gather, we run a server watching files that then sends serialized JSON data to a client which re-renders the needed template files. However, what are the clients/servers here exactly, how are they rebuilding templates is still something I cannot figure out. ^^' |
Kijewski
force-pushed
the
pr-dynamic-rendering
branch
from
edb222b to
fc3ebeb
Compare
Kijewski
force-pushed
the
pr-dynamic-rendering
branch
from
fc3ebeb to
cfd56ca
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| return Ok(ControlFlow::Continue(())); | ||
| } | ||
|
|
||
| let _ = values; // TODO |
Check notice
Code scanning / devskim
A "TODO" or similar was left in source code, possibly indicating incomplete functionality Note
Kijewski
force-pushed
the
pr-dynamic-rendering
branch
from
cfd56ca to
df17fc6
Compare
No description provided.