Bug: Don't block the async runtime for expensive functions about surrealdb

[tobiemh]

Hi @finnbear - yep these functions need improvement...

If you take a look here: 52e8954#diff-c64155b4ec93e9f70ebc55225f93a2f293fda75403be40b085f75ea363e25fe5 there used to be a file called lib/src/exe/mod.rs which contained the following code...

use executor::{Executor, Task};
use once_cell::sync::Lazy;
use std::future::Future;
use std::panic::catch_unwind;

pub fn spawn<T: Send + 'static>(future: impl Future<Output = T> + Send + 'static) -> Task<T> {
    static GLOBAL: Lazy<Executor<'_>> = Lazy::new(|| {
        std::thread::spawn(|| {
            catch_unwind(|| {
                futures::executor::block_on(GLOBAL.run(futures::future::pending::<()>()))
            })
            .ok();
        });
        Executor::new()
    });
    GLOBAL.spawn(future)
}

You could then send async futures/tasks to it...

crate::exe::spawn(async move { ..... }).await;

and that would be sent to a separate thread for the expensive computations. I only got rid of it because I was no longer using it for the query executor, but the executor library is still being used in different ways (non-multi-threaded). The code above, basically just creates a single thread for dealing with the computationally intensive futures that shouldn't run in the main async runtime (as you noted).

The reason tokio isn't included in the library is because of compiling to WASM.

Maybe we could reinstate exe module in the lib/src folder, and (after making the crypto functions async), send them to the executor thread to be processed?

[tobiemh]

Also @finnbear, I don't think there isn't a good reason for doing this for all of the crypto functions. Just in case?

[tobiemh]

On a side note, I couldn't work out a way of doing the argument checking...

surrealdb/lib/src/fnc/mod.rs

Lines 41 to 46 in 3d83f08

	pub fn synchronous(ctx: &Context<'_>, name: &str, args: Vec<Value>) -> Result<Value, Error> {
	match name {
	//
	"array::combine" => args::check(ctx, name, args, Args::Two, array::combine),
	"array::concat" => args::check(ctx, name, args, Args::Two, array::concat),
	"array::difference" => args::check(ctx, name, args, Args::Two, array::difference),

for the async functions ...

surrealdb/lib/src/fnc/mod.rs

Lines 187 to 199 in 3d83f08

	pub async fn asynchronous(ctx: &Context<'_>, name: &str, args: Vec<Value>) -> Result<Value, Error> {
	match name {
	//
	"http::head" => http::head(ctx, args).await,
	"http::get" => http::get(ctx, args).await,
	"http::put" => http::put(ctx, args).await,
	"http::post" => http::post(ctx, args).await,
	"http::patch" => http::patch(ctx, args).await,
	"http::delete" => http::delete(ctx, args).await,
	//
	_ => unreachable!(),
	}
	}

so I ended up duplicating the argument checking code in each of the http functions...

surrealdb/lib/src/fnc/http.rs

Lines 58 to 61 in 3d83f08

	_ => Err(Error::InvalidArguments {
	name: String::from("http::head"),
	message: String::from("The function expects 1 or 2 arguments."),
	}),

If you work out a way of doing that nicely, then we can use the sae argument checking for the http and crypto functions!

[tobiemh]

Also @finnbear, currently that executor only sets up 1 separate thread, which is fine for the moment. We could (in the future) use the num_cpus crate to start up the same number of threads for each CPU core (just like tokio does).

The ONE thing to remember is that threads can't be created in WASM, so sending the crypto functions to the executor thread needs to be behind the parallel feature guard (and needs to work as it does at the moment if the parallel feature is disabled).

[finnbear]

Thank you for all the info, which should allow me to formulate a PR in the near future 😃