I've been trying to write an async web service, which internally sends some data through this process (hopefully in a streaming manner, without massive buffers):
- Decompress it (xz2)
- Do some fairly cheap manipulation of the decompressed data
- Compress it again (zstd)
With the recent discussion about blocking in async code, I've been attempting to be careful about this - these (de)compression operations are fairly expensive. However, something has been throwing me off:
Both the xz and async-compression crates offer async APIs for (de)compression which don't seem to use any sort of offloading of blocking work. Would there be negative impact on scheduling if I use these APIs as-is? Do they split up the operations somehow so that each individual
poll is fast?