Open danburkert opened 1 year ago
That's a great catch! When the library was converted to async, this trait was overlooked. Fixing it could certainly be done by switching it out with its async counterpart.
A PR with a fix would be greatly appreciated.
Note the same issue is present at google drive API - upload there uses sync IO for reading the files.
The simplest way to refactor this seems to kill the ReadSeek
trait (which exposes the sync std::io::Read + std::io::Seek
) and see what blows up.
The
google-storage1
APIs use a mix of sync (std::io
) and async APIs. For instance, theupload
method takes an argument ofReadSeek
which uses blocking IO, but the method itself isasync
. Looking through the implementation, it appears that ultimately the work is done indoit
, which uses the synchronousReadSeek
instance without using something liketokio::task::block_in_place
. My understanding oftokio
is that such mixed sync and async usage is highly discouraged, since it will end up blocking unrelated async tasks while doing the sync IO operations. Am I missing something, or is this a real issue?