Is FileCache async?

[ludaavics]

Hi,

Reading through this am I correct in understanding that the use of async lock makes getting a large number of already-cached responses essentially sequential?

Thanks!

[obendidi]

I think you're right 🤔

the async_lock indeed blocks the access to the fs even if it's reading different files, the idea behind it was to avoid a race condition on r/w the same file.

Thanks for the catch

[ludaavics]

Right... if i'm thinking about this correctly, that implies large performance degradation compared to no caching? Ideally, we would want to use a file specific async lock?

Asking my friend Prof. Google, filelock acquires a lock on a specific file, but doesn't support asyncio. However:

• i think it can't be worse than current implementation? though might not be a whole lot better
• these guys seem to have an asyncio workaround. Prob not as clean a bottoms up implementation, but prob significantly better than current implementation?

[ludaavics]

Thinking about this more, @obendidi, why do we care about race condition on the same file?
Presumably the two "racers" will have received the same http response?

[obendidi]

In the unlikely edge case where we send the same request twice, and if the response has a large payload, it is very possible that the second request will try to read the file while the first request has not finished writing it

[ludaavics]

In that case, instead of the file lock, what do you think of catching any read exception and handling it by re-issuing the http request ?

[ludaavics]

I guess in your example of large payload, the second request could attempt to write before the first request is done, so the write lock should stay. So writing could still end up close to sequential (in the case of a large number of quick http requests) but at least reading from cache would be fully asynchronous.

[obendidi]

yep, and it seems there is a good library for that: https://github.com/aio-libs/aiorwlock

...., The read lock may be held simultaneously by multiple reader tasks, so long as there are no writers. The write lock is exclusive.

[obendidi]

made a PR with a possible fix, feel free to have a look
#48

[ludaavics]

In that case, instead of the file lock, what do you think of catching any read exception and handling it by re-issuing the http request ?

…

On Sat, May 28, 2022, 04:33 Ouail ***@***.***> wrote: In the unlikely edge case where we send the same request twice, and if the response has a large payload, it is very possible that the second request will try to read the file that first request has not finished writing — Reply to this email directly, view it on GitHub <#45 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAON3LGAUZV7XDDI2QMWKSLVMHK63ANCNFSM5VZEJY3A> . You are receiving this because you authored the thread.Message ID: ***@***.***>