On Thu, Mar 01, 2018 at 06:16:53PM +0100, Paolo Bonzini wrote:
> On 01/03/2018 16:46, Daniel P. Berrangé wrote:
> > On Thu, Mar 01, 2018 at 04:44:31PM +0800, Peter Xu wrote:
> >> It was originally created by qio_channel_add_watch() so it's always
> >> assigning the task to main context.  Now we use the new API called
> >> qio_channel_add_watch_source() so that we get the GSource handle rather
> >> than the tag ID.
> >>
> >> Meanwhile, caching the gsource in SocketChardev.telnet_source so that we
> >> can also do dynamic context switch when update read handlers.
> > I don't see why we would ever want to dynamically switch the
> > GMainContext in use while in middle of reading the telnet greeting.
> Maybe because the remote client hangs in the middle of the telnet
> greeting?  The user of the Chardev can't know that the initial handshake
> hasn't been done yet.

NB, the chardev will emit the CHR_EVENT_OPENED event once the connection
is successfully established, which includes completion of the telnet
and/or TLS handshake.

I'm just not seeing what code in QEMU would actually trigger a decision
to change the GMainContext, in between the accept() of the socket, and
the CHR_EVENT_OPENED, since we don't tell anyone that the accept() has
actually taken place - they first they'll know of a new client being
connected is when the CHR_EVENT_OPENED is emitted.

|: 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 :|

Reply via email to