New submission from Yury Selivanov <[email protected]>:
As discussed, we want to make Server objects more usable in async/await code
and more compatible with asyncio.run.
This is also needed to handle a use case when two or more servers are created
and need to start listening at the same time.
We propose to:
1. Add a new bool flag defaulting to True to loop.create_server and
loop.create_unix_server: start_serving. By default, loop will return a server
that is already accepting connections. When start_serving is set to False,
create_server and create_unix_server will return a server that will not listen
on its sockets.
2. A new idempotent Server.start_serving() method can be used to make server
listen on its sockets (useful when a server object was created with
start_serving=False).
3. A new Server.serve_forever() method that calls start_serving() and blocks
forever, until cancelled. When cancelled, it closes its server object.
4. A new Server.is_serving() method. This is useful to introspect a server
object in unittests.
5. Server objects should be async context managers. Server.__aexit__ should
close the server and await on Server.wait_closed().
With these new APIs, the following pattern becomes possible:
async def main():
srv = await asyncio.start_server(...)
async with srv:
await srv.serve_forever()
asyncio.run(main())
----------
components: asyncio
messages: 310657
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement Server.serve_forever and corresponding APIs
type: enhancement
versions: Python 3.7
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue32662>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
