-
Notifications
You must be signed in to change notification settings - Fork 5
Description
I believe that the cost of forcing library users to use the async API outweigh the performance benefit of using async.
In the case of this library, asyncs would make it more efficient to make a large amount of calls to a UCI engine, but this isn't really a common usecase of this library — if it is one at all.
The slowest operation, by far, will be the engine's computation, whether or not async is used.
On the other hand, async here forces the library users (including me — I'm very thankful for your library!) to adopt an async call tree and the tokio runtime.
Adopting an async call tree also means losing the ease of use of several features in rust (as async closures or async traits still aren't a thing).
For now, I am going to go with the route of wrapping async code in a blocking tokio scheduler, to stop the spread of async code in my code.
I'll also later happily investigate the possibility of refactoring the async parts of your library to use regular threads instead.
If it turns out to be feasible, then the async parts could still be kept around behind a feature flag.