Re: [pbs-devel] [RFC PATCH proxmox-backup 1/3] proxmox-rest-server: OutputFormatter: add new format_data_streaming method

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

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
> +}
> +