dora-rs/dora - dora - 开源协同云脑生态支撑系统

16 MB

Tree: 03348c5be8

Author	SHA1	Message	Date
Philipp Oppermann	03348c5be8	Redesign communication layer to be synchronous and add support for iceoryx	3 years ago
Philipp Oppermann	dbf189e239	Resolve clippy warnings	3 years ago
haixuanTao	4ff9a59ad7	Use `PyBytes` as it is faster than Vec<u8>	3 years ago
haixuanTao	6b2b082e71	Renaming `PyDoraNode` to `Node`	3 years ago
haixuanTao	d69776a85f	Adding `eyre` Error handling derived into `PyErr`	3 years ago
haixuanTao	9000e68111	Adding `__iter__` function	3 years ago
haixuanTao	1903c636cb	Refactoring `python-node-api`	3 years ago
haixuanTao	128bf6ca43	Adding `next`, `send_output` for Python node API Adding `next` and `send_output` requires an async threadpool as the communication Layer defined by the Middleware Layer returns an async Future stream. I solve this issue by adding a tokio runtime on a separater thread that is connected with two channels. One for sending data and one for receiving data. Those channel are then exposed synchronously to Python. This should not be cause for concern as channel are really fast. Looking at Zenoh Python client, they are heavily using `pyo3-asyncio` implementation of futures to pass Rust futures into Python. This can be a solution as well, but, from previous experiment, I'm concerned about performance on such solution. I have experienced that putting futures from Rust into the `asyncio` queue to be slow. I'm concerned also by mixing `async` and `sync` code in Python, as it might be blocking. This might requires 2 threadpool in Python. This might seem as heavy overhead for some operations.	3 years ago
haixuanTao	f7d288ba69	init `dora-node-api-python`	3 years ago

9 Commits (03348c5be86527d65b12111fc546e56353a39623)