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