-
Cao jin authored
The non-blocking connect mechanism is obsolete, and it doesn't work well in inet connection, because it will call getaddrinfo first and getaddrinfo will blocks on DNS lookups. Since commit e65c67e4 & d984464e, the non-blocking connect of migration goes through QIOChannel in a different manner(using a thread), and nobody use this old non-blocking connect anymore. Any newly written code which needs a non-blocking connect should use the QIOChannel code, so we can drop NonBlockingConnectHandler as a concept entirely. Suggested-by:
Daniel P. Berrange <berrange@redhat.com>
Signed-off-by:
Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by:
Mao Zhongyi <maozy.fnst@cn.fujitsu.com>
Reviewed-by:
Juan Quintela <quintela@redhat.com>
Signed-off-by:
Daniel P. Berrange <berrange@redhat.com>Cao jin authoredThe non-blocking connect mechanism is obsolete, and it doesn't work well in inet connection, because it will call getaddrinfo first and getaddrinfo will blocks on DNS lookups. Since commit e65c67e4 & d984464e, the non-blocking connect of migration goes through QIOChannel in a different manner(using a thread), and nobody use this old non-blocking connect anymore. Any newly written code which needs a non-blocking connect should use the QIOChannel code, so we can drop NonBlockingConnectHandler as a concept entirely. Suggested-by:
Daniel P. Berrange <berrange@redhat.com>
Signed-off-by:
Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by:
Mao Zhongyi <maozy.fnst@cn.fujitsu.com>
Reviewed-by:
Juan Quintela <quintela@redhat.com>
Signed-off-by:
Daniel P. Berrange <berrange@redhat.com>
Loading