Any chance of releasing future_into_py_futlike?

[winstxnhdw]

Was wondering if you would release future_into_py_futlike as a crate.

I've been using pyo3-async-runtimes to return async functions from Rust, and I found it extremely slow. About 20x slower than running my GIL-less Rust function within a Python thread and using wrap_futures on it. I haven't tested it yet but I assume future_into_py_futlike wouldn't have such an issue.

[gi0baro]

So, the issue with future_into_py_futlike is that at the moment is quite tightened to some specific Granian runtime characteristics, so it would be quite useless to just put that into a crate without the rest of the runtime.

In terms of general functionality, that function won't make anything super-special, it returns a pyclass which acts as an asyncio.Future. I think something like the windows implementation can be generalised more easily

granian/src/runtime.rs

Lines 221 to 271 in a6cfc2f

	#[allow(unused_must_use)]
	#[cfg(windows)]
	pub(crate) fn future_into_py_futlike<R, F, T>(rt: R, py: Python, fut: F) -> PyResult<Bound<PyAny>>
	where
	R: Runtime + ContextExt + Clone,
	F: Future<Output = PyResult<T>> + Send + 'static,
	T: IntoPy<PyObject> + Send + 'static,
	{
	let event_loop = rt.py_event_loop(py);
	let event_loop_ref = event_loop.clone_ref(py);
	let cancel_tx = Arc::new(tokio::sync::Notify::new());
	let rb = rt.blocking();
	let py_fut = event_loop.call_method0(py, pyo3::intern!(py, "create_future"))?;
	py_fut.call_method1(
	py,
	pyo3::intern!(py, "add_done_callback"),
	(PyFutureDoneCallback {
	cancel_tx: cancel_tx.clone(),
	},),
	)?;
	let fut_ref = py_fut.clone_ref(py);
	rt.spawn(async move {
	tokio::select! {
	result = fut => {
	let _ = rb.run(move || {
	Python::with_gil(|py| {
	let (cb, value) = match result {
	Ok(val) => (fut_ref.getattr(py, pyo3::intern!(py, "set_result")).unwrap(), val.into_py(py)),
	Err(err) => (fut_ref.getattr(py, pyo3::intern!(py, "set_exception")).unwrap(), err.into_py(py))
	};
	let _ = event_loop_ref.call_method1(py, pyo3::intern!(py, "call_soon_threadsafe"), (PyFutureResultSetter, cb, value));
	drop(fut_ref);
	drop(event_loop_ref);
	});
	});
	},
	() = cancel_tx.notified() => {
	let _ = rb.run(move || {
	Python::with_gil(|py| {
	drop(fut_ref);
	drop(event_loop_ref);
	});
	});
	}
	}
	});
	Ok(py_fut.into_bound(py))
	}

as it depends only on a glue class

granian/src/callbacks.rs

Lines 260 to 276 in a6cfc2f

	#[pyclass(frozen)]
	pub(crate) struct PyFutureDoneCallback {
	pub cancel_tx: Arc<Notify>,
	}
	#[pymethods]
	impl PyFutureDoneCallback {
	pub fn __call__(&self, fut: Bound<PyAny>) -> PyResult<()> {
	let py = fut.py();
	if { fut.getattr(pyo3::intern!(py, "cancelled"))?.call0()?.is_truthy() }.unwrap_or(false) {
	self.cancel_tx.notify_one();
	}
	Ok(())
	}
	}

and the performance difference shouldn't be so noticeable in 99% of use cases.

Given the amount of lines and still the hard dependency on tokio, I'm not sure still wether a crate would be a good idea for that..
What are your thoughts @winstxnhdw?

[winstxnhdw]

I definitely believe it’ll be incredibly helpful to everyone if it was a crate. The current ecosystem for returning futures from Rust is incredibly lacking.

I can’t figure out how you are spawning a new thread with the Granian runtime as you showed in the Windows example.

[winstxnhdw]

I came back to look at this and tried integrating your solution, but I am struggling to avoid cloning whatever data from Python inside future_into_py_futlike.