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

Refactor internals. Fix finalizers. #47

Closed

Conversation

TarasLevelUp
Copy link

What was the purpose of such a refactor:

In the process I saw some places, that could be optimised:

  • QueueReader does not need a heavy asyncio.Queue.
  • Synchroniser can be written easily without OrderedDict, which is quite heavy if used so much. Also made sure it raises same error, as it was killed with.
  • Added FrowControl to Protocol. This will give the ability to drain() from transport writes. I use it on close, so we inform server before closing connection (sending CloseOK may not be enough if buffers are full.)
  • Added some base classes for for closed connection/channel errors, but the names aren't too bright...

Feel free to comment on things, you consider needs changing. I think the way I pass ConnectionClose to be dispatched to all Writers is a bit ugly and Synchroniser's way to save future for more than 1 method can be written more cleanly.

* Remove async tasks in internals if possible.
* Refactored routing components to be more simple instead of complex ManyToMany maps
* Changed finalizers to be more straight and cover more cases.
@TarasLevelUp TarasLevelUp changed the title Refactor internals. Fix finalyzers. Refactor internals. Fix finalizers. Sep 30, 2015
@TarasLevelUp
Copy link
Author

Will add some tests to fix up coverage on weekend. Wanted to get feedback on code changes as soon as possible, so didn't look that deep on coverage, sorry.

@benjamin-hodgson
Copy link
Owner

Upon a skim-read this code looks good, but the wide scope of this pull request makes it hard to review. Do you think you could split up your changes into logical units and submit them as separate patches? For example, one PR for the QueueReader optimisation, another for the flow control stuff, etc. This will make it easier for me to review and will simplify the commit history.

@TarasLevelUp
Copy link
Author

Yes, I can. Will do on weekend then

@benjamin-hodgson
Copy link
Owner

Oh that's great, thanks. Looking forward to it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants