flutter_rust_bridge
flutter_rust_bridge copied to clipboard
fzyzcjy
Make the `WORKER_COUNT` configurable
Currently, the thread::WORKER_COUNT is 4. If we already have 4 ffi calls that are not finished at once, we can't make another ffi call immediately.
IMO, I'm not sure using a thread pool is suitable for the real-world use case, say we want to make the ffi call any times we need. So, is there something blocking us to use a plain thread::spawn？
Yes, the blocker is - thread spawn has big overhead.
Indeed I use thread pool in my app in production and it works great.
Yeah. I understand the reason to use a thread pool. But in my app, I kindly need to provide the ability to make any times FFI calls (click a button) as user want. So, I'm wondering how to implement that...
Are your ffi calls slow or fast? If they are blocking, e.g. network request, consider using async.
Feel free to PR!
AFAIK, we don't support async ffi call now. My ffi calls use the blocking channel to bridge async to sync. If we want to improve this "ffi call times" thing, what is the ideal way?
I find it maybe interesting to use Threadpool::set_num_threads() to manage thread pool size dynamically. I'll try to make a PR on that.
async should be supportable and PRs are welcomed.
http://cjycode.com/flutter_rust_bridge/contributing/design.html maybe helpful to understand the architecture.
Basically speaking, when the real rust function in api.rs returns, we do nothing but send a data pack through a port to Dart. So, it is unnecessary to be a sync function - async functions are very acceptable.
Or think like this: We now support stream very well. async functions are just like streams with just one data put into the stream. So why we cannot support it? :)
hi, what I do is change the source to use rayons global threadpool then I can reexport rayon and from my crate set the global threadpool size and get really good parallelism using rayons iters. I was thinking of making PR but dont know if this is the right way for all mabye async is better just using tokio::spawn instead of
THREAD_POOL.lock().execute(worker)
but in my usecase I have both asyncpool and threadpool for different tasks
