https://github.com/python/asyncio/pull/448
On Tue, Oct 18, 2016 at 2:30 PM Justin Mayfield <[email protected]> wrote: > 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. > > JM > > On Tue, Oct 18, 2016 at 2:19 PM Yury Selivanov <[email protected]> > wrote: > > > > On Oct 18, 2016, at 4:10 PM, Justin Mayfield <[email protected]> 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(..., > server_class=MySuperServer) > > ``` > > 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. > > Yury > >
