Unify and simplify the QHostInfo::lookupHost overloads

The three cases - with classic slot, with functor and context object,
and with lambda - are all doing the same work, they just differ in
how they signal the application code about the results.

The detour through an explicitly posted QMetaCallEvent is needed
if we have a functor or lambda; making sure that the temporary
QHostInfoResult object lives in the right thread guarantees that the
event is received in the correct thread, so we can directly call the
functor (as long as the context object is still alive).

Since we guarantee that the QHostInfoResult object lives in the
thread of the receiver, we can simply emit the signal for old-style
signal/slot connections; the regular signal/slot mechanism will do
the work for us.

Change-Id: I584df17df879af01c653e354490c4691dbedd3fa
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>

0 files changed, 0 insertions, 0 deletions