[pbs-devel] [RFC PATCH proxmox-backup 1/3] proxmox-rest-server: OutputFormatter: add new format_data_streaming method
Thomas Lamprecht
t.lamprecht at proxmox.com
Wed Feb 23 10:20:48 CET 2022
On 17.02.22 10:40, Dominik Csapak wrote:
> +fn start_data_streaming(value: Value, data: Box<dyn SerializableReturn + Send>) -> tokio::sync::mpsc::Receiver<Result<Vec<u8>, Error>> {
> + let (writer, reader) = tokio::sync::mpsc::channel(1);
> +
> + std::thread::spawn(move || {
just for the record, spawning a separate thread for every request isn't
a good idea performance wise, while the cost is lower than say forking,
its still non-negligible and a few users having the gui open will result
in hundreds of threads spawned per minute; iow. system threads should
only be spawned for long running (as in about as long running as the
whole programs lifetime) tasks, not for one-time short lived tasks with
a definite purpose.
Using tokio's spawn_blocking is nicer for such things as while it also
may spawn a thread it lets the thread idle for 10s after last task
completion to wait for new work before exiting again. Having a PBS web
interface dashboard open shows ~8 XHR request in 10s, so it's quite
likely that we'd only ever have one such thread reused constantly per
user-session, reducing costs a lot.
btw., as it was questioned during off-list talk: block_in_place makes
only then sense for blocking code if spawn_blocking cannot be used due
to missing Send + 'static guarantees on the fn to call.
> + let output = proxmox_async::blocking::SenderWriter::from_sender(writer);
> + let mut output = std::io::BufWriter::new(output);
> + let mut serializer = serde_json::Serializer::new(&mut output);
> + let _ = data.sender_serialize(&mut serializer, value);
> + });
> +
> + reader
> +}
> +
More information about the pbs-devel
mailing list