Documentation regarding Async support

[FridayPush]

Exploring PyrateLimiter and I'm stumbling a bit on the documentation to understand when Async is supported. It's probably my ignorance of the project but it appears that in order to use Async with PyrateLimiter I must be using Redis as the backend?

If it's accurate to say a Redis backend is needed for Async functionality I think it would be worth modifying the 'Key Concepts' section to reference the need for a Redis Backend:

Handles async/sync context seamlessly (everything just works by adding/removing async/await keyword to the user's code)

Additionally the documentation for backends lists InMemory doesn't support async, Redis does, and SQLite and Postgres do not mention whether they support async or not.

[FridayPush]

Related to Documentation but the contribution guide file might need to list what local services like Redis, Postgres(?) need to be running for tests to succeed, along with any credential/config setup? Went to make a PR for the other issue I opened and local tests fail with:

Went to work on a Pull Request but found that a local redis environment is required:

FAILED tests/test_bucket_all.py::test_bucket_01[clock0-create_async_redis_bucket] - redis.exceptions.ConnectionError: Error connecting to localhost:6379. Multiple exceptions: [Errno 61] Connect call failed ('127.0.0.1', 6379), [Errno 61] Connect call failed ('::1', 6379, 0, 0).

[vutran1710]

Ah there is a docker compose in the repo you can use for testing i believe?

[vutran1710]

And regarding the async support, its not just redis that can work with async. When you use a clock backend that sync clock remotely in async manner, the limiter still works too.

[vutran1710]

Updated!

[jscheel]

I think I am still misunderstanding async limiters @vutran1710. The new documentation you adde says that if your clock or your bucket backend is async, the limiter will be async. But the TimeAsyncClock is documented as "for testing only". Is there no way to create an InMemory bucket with an async limiter? Basically, one that will use asyncio.sleep during the delay phase?

[vutran1710]

I think I am still misunderstanding async limiters @vutran1710. The new documentation you adde says that if your clock or your bucket backend is async, the limiter will be async. But the TimeAsyncClock is documented as "for testing only". Is there no way to create an InMemory bucket with an async limiter? Basically, one that will use asyncio.sleep during the delay phase?

Why do you want an async InMemory limiter? Asking because im curious about how you are using it.

To make inmemory limiter async, you can use async clock. Yes i did note it as "for testing" but you can still use. But it wont give you any extra benefit compared to normal clock.

[jscheel]

@vutran1710 hmm, so the benefit of it being async is that the wait happens via an asyncio.sleep() call instead of a time.sleep() call. This won't block the entire process, correct? Specifically, the idea would be to be able to wait until capacity is available before proceeding to the next line of code, but to not block other futures that may be running concurrently.

[vutran1710]

@vutran1710 hmm, so the benefit of it being async is that the wait happens via an asyncio.sleep() call instead of a time.sleep() call. This won't block the entire process, correct? Specifically, the idea would be to be able to wait until capacity is available before proceeding to the next line of code, but to not block other futures that may be running concurrently.

Indeed. But for that to happen, the "peek" method must be async - meaning it will be async sleep if your bucket "peek" method is async.

If you need that i guess you can extend the InMemory bucket and override the method "peek".

[jscheel]

The peek method of the InMemory bucket doesn't need to be async though. All it is doing is simple list access and counting. The InMemory bucket seems fine as is, but the delay_or_raise call in the Limiter is where it decides if it needs to do a sync or async sleep.