That's interesting, I hadn't seen that method yet.  I'd still like to
pursue pause/resume on Server for this use-case, but I might make use of
that in the future for more complex servers.


On Tue, Oct 18, 2016 at 2:19 PM Yury Selivanov <> wrote:

> On Oct 18, 2016, at 4:10 PM, Justin Mayfield <> wrote:
> Re 3.6 freeze, This is understandable.
> I just wanted to make sure I wasn't missing something in the first
place.  I can submit a PR/Issue that focuses on Server.pause_serving and
resume_serving if that's the most sensible place for this.  A param to
start_server such as `connection_limit` could be added later using those
interfaces or I could add that in the same PR.
> Mild tangent, while I was looking at the code I was wondering if it made
sense to allow users to bring their own Server subclasses via an optional
kwarg to create_server, along the lines of
> ```
> class MySuperServer(asyncio.Server):
>      pass
> my_super_server = await asyncio.start_server(...,
> ```

We try to avoid promoting use of inheritance in asyncio APIs, so my first
reaction to this would be “no”.  IMO pause_serving / resume_serving methods
are easy to understand and use.

BTW, another way to solve your problem in asyncio in 3.6 is to create your
own accept loop implementation and use the new 'loop.
connect_accepted_socket' API.


Reply via email to