Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
On Thu, Feb 3, 2022 at 4:19 AM Kevin Wolf wrote:
>
> Am 02.02.2022 um 20:08 hat John Snow geschrieben:
> > > I guess the relevant question in the context of this patch is whether
> > > sync.py will need a similar two-phase setup as legacy.py. Do you think
> > > you can do without it when you have to reintroduce this behaviour here
> > > to fix bugs?
> > >
> >
> > Hm, honestly, no. I think you'll still need the two-phase in the sync
> > version no matter what -- if you expect to be able to launch QMP and
> > QEMU from the same process, anyway. I suppose it's just a matter of
> > what you *call* it and what/where the arguments are.
> >
> > I could just call it bind(), and it does whatever it needs to (Either
> > creating a socket or, in 3.7+, instantiating more of the asyncio loop
> > machinery).
> > The signature for accept() would need to change to (perhaps)
> > optionally accepting no arguments; i.e. you can do either of the
> > following:
> >
> > (1) qmp.bind('/tmp/sock')
> > qmp.accept()
> >
> > (2) qmp.accept('/tmp/sock')
> >
> > The risk is that the interface is just a touch more complex, the docs
> > get a bit more cluttered, there's a slight loss of clarity, the
> > accept() method would need to check to make sure you didn't give it an
> > address argument if you've already given it one, etc. Necessary
> > trade-off for the flexibility, though.
>
> Hm, how about copying the create_server() interface instead? So it
> would become:
>
> (1) qmp.create_server('/tmp/sock', start_serving=False)
> qmp.start_serving()
>
> (2) qmp.create_server('/tmp/sock')
>
> Then you get the connection details only in a single place. (The names
> should probably be changed because we're still a QMP client even though
> we're technically the server on the socket level, but you get the idea.)
Good idea. I'll experiment.
(I'm worried that the way I initially factored the code to begin with
might make this ugly, but maybe I'm just dreading nothing. I'll have
to see.)
Thanks for taking a look!
--js
Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
On Thu, Feb 3, 2022 at 4:38 AM Daniel P. Berrangé wrote:
>
> On Wed, Feb 02, 2022 at 02:08:59PM -0500, John Snow wrote:
> > On Tue, Feb 1, 2022 at 2:46 PM Kevin Wolf wrote:
> > >
> > > Am 01.02.2022 um 19:32 hat John Snow geschrieben:
> > > > On Tue, Feb 1, 2022 at 8:21 AM Kevin Wolf wrote:
> > > > >
> > > > > Am 01.02.2022 um 05:11 hat John Snow geschrieben:
> > > > > > The synchronous QMP library would bind to the server address during
> > > > > > __init__(). The new library delays this to the accept() call,
> > > > > > because
> > > > > > binding occurs inside of the call to start_[unix_]server(), which
> > > > > > is an
> > > > > > async method -- so it cannot happen during __init__ anymore.
> > > > > >
> > > > > > Python 3.7+ adds the ability to create the server (and thus the
> > > > > > bind()
> > > > > > call) and begin the active listening in separate steps, but we don't
> > > > > > have that functionality in 3.6, our current minimum.
> > > > > >
> > > > > > Therefore ... Add a temporary workaround that allows the synchronous
> > > > > > version of the client to bind the socket in advance, guaranteeing
> > > > > > that
> > > > > > there will be a UNIX socket in the filesystem ready for the QEMU
> > > > > > client
> > > > > > to connect to without a race condition.
> > > > > >
> > > > > > (Yes, it's a bit ugly. Fixing it more nicely will have to wait
> > > > > > until our
> > > > > > minimum Python version is 3.7+.)
> > > I guess the relevant question in the context of this patch is whether
> > > sync.py will need a similar two-phase setup as legacy.py. Do you think
> > > you can do without it when you have to reintroduce this behaviour here
> > > to fix bugs?
> > >
> >
> > Hm, honestly, no. I think you'll still need the two-phase in the sync
> > version no matter what -- if you expect to be able to launch QMP and
> > QEMU from the same process, anyway. I suppose it's just a matter of
> > what you *call* it and what/where the arguments are.
> >
> > I could just call it bind(), and it does whatever it needs to (Either
> > creating a socket or, in 3.7+, instantiating more of the asyncio loop
> > machinery).
> > The signature for accept() would need to change to (perhaps)
> > optionally accepting no arguments; i.e. you can do either of the
> > following:
> >
> > (1) qmp.bind('/tmp/sock')
> > qmp.accept()
> >
> > (2) qmp.accept('/tmp/sock')
> >
> > The risk is that the interface is just a touch more complex, the docs
> > get a bit more cluttered, there's a slight loss of clarity, the
> > accept() method would need to check to make sure you didn't give it an
> > address argument if you've already given it one, etc. Necessary
> > trade-off for the flexibility, though.
>
> Doing a bind() inside an accept() call is really strange
> design IMHO.
>
Yeah, it was possibly a mistake to use the same names as the very
famous and widely known POSIX calls. I didn't intend for them to be
precisely 1:1.
What I intended was that each QMPClient() object could either receive
an incoming connection or dial out and make one. I happened to name
these accept() and connect(). Under the hood, we do "whatever we have
to" in order to make those methods work. This was the simplest
possible interface I could imagine; and it also mimics the (sync) qmp
code in python/qemu/qmp. That code doesn't have distinct
bind-listen-accept steps; it performs bind and listen immediately
during __init__, then socket.accept() is called during the accept()
method call.
However, In python asyncio, we're encouraged to use the
asyncio.start_server() and asyncio.start_unix_server() functions
instead. These are async calls, and they cannot occur during
__init__(), because __init__() isn't an async coroutine. This compels
us to move the bind step out of init and into an async method. In the
interest of keeping the new interface looking very similar to the old
one, I pushed the entirety of the bind-listen-accept sequence into the
async accept(...) method.
A little weird, but that's why it happened that way. (The concept of a
QMP client being the socket server is also a little weird and defies
the traditional expectation, too, IMO. Oh well, we're here now.)
For comparison, the sync interface:
qmp = QEMUMonitorProtocol('qemu.sock', server=True) # bind(), listen()
qmp.accept() # accept()
And the async interface:
qmp = QMPClient()
await qmp.accept('qemu.sock') # bind, listen, and accept
That said, I could probably make this interface a lot more traditional
for actual /servers/. I have patches to add a QMPServer() class, but
it adopted the "exactly one peer" limitation that QMPClient() has. If
you think there is some value in developing the idea further, I could
refactor the code to be a *lot* more traditional and have a listening
server that acts as a factory for generating connected client
instances. It just isn't something that I think I'll have merge ready
in less than a week.
> bind() is a one-time-only initialization operation
Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
On Wed, Feb 02, 2022 at 02:08:59PM -0500, John Snow wrote:
> On Tue, Feb 1, 2022 at 2:46 PM Kevin Wolf wrote:
> >
> > Am 01.02.2022 um 19:32 hat John Snow geschrieben:
> > > On Tue, Feb 1, 2022 at 8:21 AM Kevin Wolf wrote:
> > > >
> > > > Am 01.02.2022 um 05:11 hat John Snow geschrieben:
> > > > > The synchronous QMP library would bind to the server address during
> > > > > __init__(). The new library delays this to the accept() call, because
> > > > > binding occurs inside of the call to start_[unix_]server(), which is
> > > > > an
> > > > > async method -- so it cannot happen during __init__ anymore.
> > > > >
> > > > > Python 3.7+ adds the ability to create the server (and thus the bind()
> > > > > call) and begin the active listening in separate steps, but we don't
> > > > > have that functionality in 3.6, our current minimum.
> > > > >
> > > > > Therefore ... Add a temporary workaround that allows the synchronous
> > > > > version of the client to bind the socket in advance, guaranteeing that
> > > > > there will be a UNIX socket in the filesystem ready for the QEMU
> > > > > client
> > > > > to connect to without a race condition.
> > > > >
> > > > > (Yes, it's a bit ugly. Fixing it more nicely will have to wait until
> > > > > our
> > > > > minimum Python version is 3.7+.)
> > I guess the relevant question in the context of this patch is whether
> > sync.py will need a similar two-phase setup as legacy.py. Do you think
> > you can do without it when you have to reintroduce this behaviour here
> > to fix bugs?
> >
>
> Hm, honestly, no. I think you'll still need the two-phase in the sync
> version no matter what -- if you expect to be able to launch QMP and
> QEMU from the same process, anyway. I suppose it's just a matter of
> what you *call* it and what/where the arguments are.
>
> I could just call it bind(), and it does whatever it needs to (Either
> creating a socket or, in 3.7+, instantiating more of the asyncio loop
> machinery).
> The signature for accept() would need to change to (perhaps)
> optionally accepting no arguments; i.e. you can do either of the
> following:
>
> (1) qmp.bind('/tmp/sock')
> qmp.accept()
>
> (2) qmp.accept('/tmp/sock')
>
> The risk is that the interface is just a touch more complex, the docs
> get a bit more cluttered, there's a slight loss of clarity, the
> accept() method would need to check to make sure you didn't give it an
> address argument if you've already given it one, etc. Necessary
> trade-off for the flexibility, though.
Doing a bind() inside an accept() call is really strange
design IMHO.
bind() is a one-time-only initialization operation for startup,
where as accept() is a runtime operation invoked repeatedly.
bind() is also an op that is reasonably likely to fail
due to something already holding the socket address, and thus
an error condition that you want to report to an application
during its early startup phase.
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
Am 02.02.2022 um 20:08 hat John Snow geschrieben:
> > I guess the relevant question in the context of this patch is whether
> > sync.py will need a similar two-phase setup as legacy.py. Do you think
> > you can do without it when you have to reintroduce this behaviour here
> > to fix bugs?
> >
>
> Hm, honestly, no. I think you'll still need the two-phase in the sync
> version no matter what -- if you expect to be able to launch QMP and
> QEMU from the same process, anyway. I suppose it's just a matter of
> what you *call* it and what/where the arguments are.
>
> I could just call it bind(), and it does whatever it needs to (Either
> creating a socket or, in 3.7+, instantiating more of the asyncio loop
> machinery).
> The signature for accept() would need to change to (perhaps)
> optionally accepting no arguments; i.e. you can do either of the
> following:
>
> (1) qmp.bind('/tmp/sock')
> qmp.accept()
>
> (2) qmp.accept('/tmp/sock')
>
> The risk is that the interface is just a touch more complex, the docs
> get a bit more cluttered, there's a slight loss of clarity, the
> accept() method would need to check to make sure you didn't give it an
> address argument if you've already given it one, etc. Necessary
> trade-off for the flexibility, though.
Hm, how about copying the create_server() interface instead? So it
would become:
(1) qmp.create_server('/tmp/sock', start_serving=False)
qmp.start_serving()
(2) qmp.create_server('/tmp/sock')
Then you get the connection details only in a single place. (The names
should probably be changed because we're still a QMP client even though
we're technically the server on the socket level, but you get the idea.)
Kevin
Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
On Tue, Feb 1, 2022 at 2:46 PM Kevin Wolf wrote: > > Am 01.02.2022 um 19:32 hat John Snow geschrieben: > > On Tue, Feb 1, 2022 at 8:21 AM Kevin Wolf wrote: > > > > > > Am 01.02.2022 um 05:11 hat John Snow geschrieben: > > > > The synchronous QMP library would bind to the server address during > > > > __init__(). The new library delays this to the accept() call, because > > > > binding occurs inside of the call to start_[unix_]server(), which is an > > > > async method -- so it cannot happen during __init__ anymore. > > > > > > > > Python 3.7+ adds the ability to create the server (and thus the bind() > > > > call) and begin the active listening in separate steps, but we don't > > > > have that functionality in 3.6, our current minimum. > > > > > > > > Therefore ... Add a temporary workaround that allows the synchronous > > > > version of the client to bind the socket in advance, guaranteeing that > > > > there will be a UNIX socket in the filesystem ready for the QEMU client > > > > to connect to without a race condition. > > > > > > > > (Yes, it's a bit ugly. Fixing it more nicely will have to wait until our > > > > minimum Python version is 3.7+.) > > > > > > > > Signed-off-by: John Snow > > > > --- > > > > python/qemu/aqmp/legacy.py | 3 +++ > > > > python/qemu/aqmp/protocol.py | 41 +--- > > > > 2 files changed, 41 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/python/qemu/aqmp/legacy.py b/python/qemu/aqmp/legacy.py > > > > index 0890f95b16..6baa5f3409 100644 > > > > --- a/python/qemu/aqmp/legacy.py > > > > +++ b/python/qemu/aqmp/legacy.py > > > > @@ -56,6 +56,9 @@ def __init__(self, address: SocketAddrT, > > > > self._address = address > > > > self._timeout: Optional[float] = None > > > > > > > > +if server: > > > > +self._aqmp._bind_hack(address) # pylint: > > > > disable=protected-access > > > > > > I feel that this is the only part that really makes it ugly. Do you > > > really think this way is so bad that we can't make it an official public > > > interface in the library? > > > > > > Kevin > > > > > > > Good question. > > > > I felt like I'd rather use the 'start_serving' parameter of > > loop.create_server(...), added in python 3.7; see > > https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.create_server > > Python 3.6 is already EOL, but we still depend on it for our build and > > I wasn't prepared to write the series that forces us on to 3.7, > > because RHEL uses 3.6 as its native python. I'll have to update the > > docker files, etc -- and I'm sure people will be kind of unhappy with > > this, so I am putting it off. People were unhappy enough with the move > > to Python 3.6. > > Yes, I understand. In theory - I haven't really thought much about it - > it feels like whether you create a separate socket in a first step and > pass it to the server that is created in the second step (for 3.6) or > you start an idle server in the first step and then let it start serving > in the second step (for 3.7+) should be an implementation detail if we > get the external API right. > > > I also felt as though the async version has no real need for a > > separate bind step -- you can just start the server in a coroutine and > > wait until it yields, then proceed to launch QEMU. It's easy in that > > paradigm. If this bind step is only for the benefit of the legacy.py > > interface, I thought maybe it wasn't wise to commit to supporting it > > if it was something I wanted to get rid of soon anyway. There's also > > the ugliness that if you use the early bind step, the arguments passed > > to accept() are now ignored, which is kind of ugly, too. It's not a > > *great* interface. It doesn't spark joy. > > Right, that's probably a sign that the interfaces aren't completely > right. I'm not sure which interfaces. As long as it's just _bind_hack() > and it's only used in an API that is going away in the future, that's no > problem. But it could also be a sign that the public interfaces aren't > flexible enough. > Yeah, I agree. It's not flexible enough. I think the sync.py development will force me to understand where I have come to rest on the conveniences of asyncio and force the design to be more flexible overall. > > I have some patches that are building a "sync.py" module that's meant > > to replace "legacy.py", and it's in the development of that module > > that I expect to either remove the bits I am unhappy with, or commit > > to supporting necessary infrastructure that's just simply required for > > a functional synchronous interface to work. I planned to start > > versioning the "qemu.qmp" package at 0.0.1, and the version that drops > > legacy.py I intend to version at 0.1.0. > > If I understand these version numbers correctly, this also implies that > there is no compatibility promise yet. So maybe what to make a public > interface isn't even a big concern yet. Right. (Still, I didn't want
Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
Am 01.02.2022 um 19:32 hat John Snow geschrieben: > On Tue, Feb 1, 2022 at 8:21 AM Kevin Wolf wrote: > > > > Am 01.02.2022 um 05:11 hat John Snow geschrieben: > > > The synchronous QMP library would bind to the server address during > > > __init__(). The new library delays this to the accept() call, because > > > binding occurs inside of the call to start_[unix_]server(), which is an > > > async method -- so it cannot happen during __init__ anymore. > > > > > > Python 3.7+ adds the ability to create the server (and thus the bind() > > > call) and begin the active listening in separate steps, but we don't > > > have that functionality in 3.6, our current minimum. > > > > > > Therefore ... Add a temporary workaround that allows the synchronous > > > version of the client to bind the socket in advance, guaranteeing that > > > there will be a UNIX socket in the filesystem ready for the QEMU client > > > to connect to without a race condition. > > > > > > (Yes, it's a bit ugly. Fixing it more nicely will have to wait until our > > > minimum Python version is 3.7+.) > > > > > > Signed-off-by: John Snow > > > --- > > > python/qemu/aqmp/legacy.py | 3 +++ > > > python/qemu/aqmp/protocol.py | 41 +--- > > > 2 files changed, 41 insertions(+), 3 deletions(-) > > > > > > diff --git a/python/qemu/aqmp/legacy.py b/python/qemu/aqmp/legacy.py > > > index 0890f95b16..6baa5f3409 100644 > > > --- a/python/qemu/aqmp/legacy.py > > > +++ b/python/qemu/aqmp/legacy.py > > > @@ -56,6 +56,9 @@ def __init__(self, address: SocketAddrT, > > > self._address = address > > > self._timeout: Optional[float] = None > > > > > > +if server: > > > +self._aqmp._bind_hack(address) # pylint: > > > disable=protected-access > > > > I feel that this is the only part that really makes it ugly. Do you > > really think this way is so bad that we can't make it an official public > > interface in the library? > > > > Kevin > > > > Good question. > > I felt like I'd rather use the 'start_serving' parameter of > loop.create_server(...), added in python 3.7; see > https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.create_server > Python 3.6 is already EOL, but we still depend on it for our build and > I wasn't prepared to write the series that forces us on to 3.7, > because RHEL uses 3.6 as its native python. I'll have to update the > docker files, etc -- and I'm sure people will be kind of unhappy with > this, so I am putting it off. People were unhappy enough with the move > to Python 3.6. Yes, I understand. In theory - I haven't really thought much about it - it feels like whether you create a separate socket in a first step and pass it to the server that is created in the second step (for 3.6) or you start an idle server in the first step and then let it start serving in the second step (for 3.7+) should be an implementation detail if we get the external API right. > I also felt as though the async version has no real need for a > separate bind step -- you can just start the server in a coroutine and > wait until it yields, then proceed to launch QEMU. It's easy in that > paradigm. If this bind step is only for the benefit of the legacy.py > interface, I thought maybe it wasn't wise to commit to supporting it > if it was something I wanted to get rid of soon anyway. There's also > the ugliness that if you use the early bind step, the arguments passed > to accept() are now ignored, which is kind of ugly, too. It's not a > *great* interface. It doesn't spark joy. Right, that's probably a sign that the interfaces aren't completely right. I'm not sure which interfaces. As long as it's just _bind_hack() and it's only used in an API that is going away in the future, that's no problem. But it could also be a sign that the public interfaces aren't flexible enough. > I have some patches that are building a "sync.py" module that's meant > to replace "legacy.py", and it's in the development of that module > that I expect to either remove the bits I am unhappy with, or commit > to supporting necessary infrastructure that's just simply required for > a functional synchronous interface to work. I planned to start > versioning the "qemu.qmp" package at 0.0.1, and the version that drops > legacy.py I intend to version at 0.1.0. If I understand these version numbers correctly, this also implies that there is no compatibility promise yet. So maybe what to make a public interface isn't even a big concern yet. I guess the relevant question in the context of this patch is whether sync.py will need a similar two-phase setup as legacy.py. Do you think you can do without it when you have to reintroduce this behaviour here to fix bugs? > All that said, I'm fairly wishy-washy on it, so if you have some > strong feelings, lemme know. There may be some real utility in just > doubling down on always creating our own socket object. I just haven't > thought through everything
Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
On Tue, Feb 1, 2022 at 8:21 AM Kevin Wolf wrote: > > Am 01.02.2022 um 05:11 hat John Snow geschrieben: > > The synchronous QMP library would bind to the server address during > > __init__(). The new library delays this to the accept() call, because > > binding occurs inside of the call to start_[unix_]server(), which is an > > async method -- so it cannot happen during __init__ anymore. > > > > Python 3.7+ adds the ability to create the server (and thus the bind() > > call) and begin the active listening in separate steps, but we don't > > have that functionality in 3.6, our current minimum. > > > > Therefore ... Add a temporary workaround that allows the synchronous > > version of the client to bind the socket in advance, guaranteeing that > > there will be a UNIX socket in the filesystem ready for the QEMU client > > to connect to without a race condition. > > > > (Yes, it's a bit ugly. Fixing it more nicely will have to wait until our > > minimum Python version is 3.7+.) > > > > Signed-off-by: John Snow > > --- > > python/qemu/aqmp/legacy.py | 3 +++ > > python/qemu/aqmp/protocol.py | 41 +--- > > 2 files changed, 41 insertions(+), 3 deletions(-) > > > > diff --git a/python/qemu/aqmp/legacy.py b/python/qemu/aqmp/legacy.py > > index 0890f95b16..6baa5f3409 100644 > > --- a/python/qemu/aqmp/legacy.py > > +++ b/python/qemu/aqmp/legacy.py > > @@ -56,6 +56,9 @@ def __init__(self, address: SocketAddrT, > > self._address = address > > self._timeout: Optional[float] = None > > > > +if server: > > +self._aqmp._bind_hack(address) # pylint: > > disable=protected-access > > I feel that this is the only part that really makes it ugly. Do you > really think this way is so bad that we can't make it an official public > interface in the library? > > Kevin > Good question. I felt like I'd rather use the 'start_serving' parameter of loop.create_server(...), added in python 3.7; see https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.create_server Python 3.6 is already EOL, but we still depend on it for our build and I wasn't prepared to write the series that forces us on to 3.7, because RHEL uses 3.6 as its native python. I'll have to update the docker files, etc -- and I'm sure people will be kind of unhappy with this, so I am putting it off. People were unhappy enough with the move to Python 3.6. I also felt as though the async version has no real need for a separate bind step -- you can just start the server in a coroutine and wait until it yields, then proceed to launch QEMU. It's easy in that paradigm. If this bind step is only for the benefit of the legacy.py interface, I thought maybe it wasn't wise to commit to supporting it if it was something I wanted to get rid of soon anyway. There's also the ugliness that if you use the early bind step, the arguments passed to accept() are now ignored, which is kind of ugly, too. It's not a *great* interface. It doesn't spark joy. I have some patches that are building a "sync.py" module that's meant to replace "legacy.py", and it's in the development of that module that I expect to either remove the bits I am unhappy with, or commit to supporting necessary infrastructure that's just simply required for a functional synchronous interface to work. I planned to start versioning the "qemu.qmp" package at 0.0.1, and the version that drops legacy.py I intend to version at 0.1.0. All that said, I'm fairly wishy-washy on it, so if you have some strong feelings, lemme know. There may be some real utility in just doubling down on always creating our own socket object. I just haven't thought through everything here, admittedly. --js
Re: [PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
Am 01.02.2022 um 05:11 hat John Snow geschrieben: > The synchronous QMP library would bind to the server address during > __init__(). The new library delays this to the accept() call, because > binding occurs inside of the call to start_[unix_]server(), which is an > async method -- so it cannot happen during __init__ anymore. > > Python 3.7+ adds the ability to create the server (and thus the bind() > call) and begin the active listening in separate steps, but we don't > have that functionality in 3.6, our current minimum. > > Therefore ... Add a temporary workaround that allows the synchronous > version of the client to bind the socket in advance, guaranteeing that > there will be a UNIX socket in the filesystem ready for the QEMU client > to connect to without a race condition. > > (Yes, it's a bit ugly. Fixing it more nicely will have to wait until our > minimum Python version is 3.7+.) > > Signed-off-by: John Snow > --- > python/qemu/aqmp/legacy.py | 3 +++ > python/qemu/aqmp/protocol.py | 41 +--- > 2 files changed, 41 insertions(+), 3 deletions(-) > > diff --git a/python/qemu/aqmp/legacy.py b/python/qemu/aqmp/legacy.py > index 0890f95b16..6baa5f3409 100644 > --- a/python/qemu/aqmp/legacy.py > +++ b/python/qemu/aqmp/legacy.py > @@ -56,6 +56,9 @@ def __init__(self, address: SocketAddrT, > self._address = address > self._timeout: Optional[float] = None > > +if server: > +self._aqmp._bind_hack(address) # pylint: > disable=protected-access I feel that this is the only part that really makes it ugly. Do you really think this way is so bad that we can't make it an official public interface in the library? Kevin
[PATCH v4 4/4] python/aqmp: add socket bind step to legacy.py
The synchronous QMP library would bind to the server address during
__init__(). The new library delays this to the accept() call, because
binding occurs inside of the call to start_[unix_]server(), which is an
async method -- so it cannot happen during __init__ anymore.
Python 3.7+ adds the ability to create the server (and thus the bind()
call) and begin the active listening in separate steps, but we don't
have that functionality in 3.6, our current minimum.
Therefore ... Add a temporary workaround that allows the synchronous
version of the client to bind the socket in advance, guaranteeing that
there will be a UNIX socket in the filesystem ready for the QEMU client
to connect to without a race condition.
(Yes, it's a bit ugly. Fixing it more nicely will have to wait until our
minimum Python version is 3.7+.)
Signed-off-by: John Snow
---
python/qemu/aqmp/legacy.py | 3 +++
python/qemu/aqmp/protocol.py | 41 +---
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/python/qemu/aqmp/legacy.py b/python/qemu/aqmp/legacy.py
index 0890f95b16..6baa5f3409 100644
--- a/python/qemu/aqmp/legacy.py
+++ b/python/qemu/aqmp/legacy.py
@@ -56,6 +56,9 @@ def __init__(self, address: SocketAddrT,
self._address = address
self._timeout: Optional[float] = None
+if server:
+self._aqmp._bind_hack(address) # pylint: disable=protected-access
+
_T = TypeVar('_T')
def _sync(
diff --git a/python/qemu/aqmp/protocol.py b/python/qemu/aqmp/protocol.py
index 50e973c2f2..33358f5cd7 100644
--- a/python/qemu/aqmp/protocol.py
+++ b/python/qemu/aqmp/protocol.py
@@ -15,6 +15,7 @@
from enum import Enum
from functools import wraps
import logging
+import socket
from ssl import SSLContext
from typing import (
Any,
@@ -238,6 +239,9 @@ def __init__(self, name: Optional[str] = None) -> None:
self._runstate = Runstate.IDLE
self._runstate_changed: Optional[asyncio.Event] = None
+# Workaround for bind()
+self._sock: Optional[socket.socket] = None
+
def __repr__(self) -> str:
cls_name = type(self).__name__
tokens = []
@@ -427,6 +431,34 @@ async def _establish_connection(
else:
await self._do_connect(address, ssl)
+def _bind_hack(self, address: Union[str, Tuple[str, int]]) -> None:
+"""
+Used to create a socket in advance of accept().
+
+This is a workaround to ensure that we can guarantee timing of
+precisely when a socket exists to avoid a connection attempt
+bouncing off of nothing.
+
+Python 3.7+ adds a feature to separate the server creation and
+listening phases instead, and should be used instead of this
+hack.
+"""
+if isinstance(address, tuple):
+family = socket.AF_INET
+else:
+family = socket.AF_UNIX
+
+sock = socket.socket(family, socket.SOCK_STREAM)
+sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
+
+try:
+sock.bind(address)
+except:
+sock.close()
+raise
+
+self._sock = sock
+
@upper_half
async def _do_accept(self, address: SocketAddrT,
ssl: Optional[SSLContext] = None) -> None:
@@ -464,24 +496,27 @@ async def _client_connected_cb(reader:
asyncio.StreamReader,
if isinstance(address, tuple):
coro = asyncio.start_server(
_client_connected_cb,
-host=address[0],
-port=address[1],
+host=None if self._sock else address[0],
+port=None if self._sock else address[1],
ssl=ssl,
backlog=1,
limit=self._limit,
+sock=self._sock,
)
else:
coro = asyncio.start_unix_server(
_client_connected_cb,
-path=address,
+path=None if self._sock else address,
ssl=ssl,
backlog=1,
limit=self._limit,
+sock=self._sock,
)
server = await coro # Starts listening
await connected.wait() # Waits for the callback to fire (and finish)
assert server is None
+self._sock = None
self.logger.debug("Connection accepted.")
--
2.31.1
