Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async issues #3

Open
stj opened this issue Jan 11, 2019 · 5 comments
Open

Async issues #3

stj opened this issue Jan 11, 2019 · 5 comments
Labels
bug Something isn't working feature New feature or request
Milestone

Comments

@stj
Copy link

stj commented Jan 11, 2019

Just stumbled on your project and looked over your code to see if it would fit my use cases.
Two things immediately caught my eye and I like to raise them to the maintainer(s).

@arlyon
Copy link
Owner

arlyon commented Jan 11, 2019

Hey thanks for the interest. I didn't know that about RLock and will have a look at it soon. I haven't had need for redis (although that is changing soon) and haven't given it a critical look. I'd be happy to accept a PR to support it if youre desperate or otherwise I'll probably have some time to work on it soon.

@stj
Copy link
Author

stj commented Jan 11, 2019

Adding aredis support will change the signature of every method to become a coro. Will be hard to do that in a backwards incompatible way. Before working on a PR I feel this should be talked through and agreed on.

@arlyon
Copy link
Owner

arlyon commented Jan 13, 2019

Yes you are right I think this library needs a bit of love. I'm going to rework the locking used in the original fork and look at the changes aioredis would require. I haven't even converted the original tests over yet so that would need doing as well.

@arlyon arlyon added this to the 2.0 milestone Jan 13, 2019
@arlyon arlyon added bug Something isn't working feature New feature or request labels Jan 14, 2019
@arlyon
Copy link
Owner

arlyon commented Jan 14, 2019

Alright so after a little bit of work (docs, CI, some fixes) we're at a point where adding this is reasonable. Looking at it again, using the lock makes no sense. It is rare that anyone is going to be using threads with asyncio anyways, so I ripped it out.

I've been trying to contain "async creep" as much as possible (which is why call and call_async a seperate) however like you said with aredis I think we have no choice but to go all in.

Ideally calling a synchronous function over the breaker shouldn't need to be awaited so with the need for async backends and async event listeners (that I'm about to implement) maybe some sort of "feature detection" would be useful. With the risk of over-complicating everything:

Storage Backend Listeners Supported Functions
Async Sync call_async
Sync Async call_async
Sync Sync call, call_async

That way completely synchronous code can still use the library synchronously if it doesn't require any async features.

I can do the needed work to allow for this, and then you can build the aredis module on top.

@stj
Copy link
Author

stj commented Jan 14, 2019

Nice!
I have not read up on how the lock was used. Right now I feel that redis lock is useful for distributed services but I would not worry about that now.

Happy to look into the async redis support once you finished your refactor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working feature New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants