> I just tried a test calling that function with 0 as timeout (so it always > timeouts) and sometimes it waits until 1 second so it is quite clear it is > waiting for the thread.
Yes, Thiago explained to me the notion of cancellation points, and proved me wrong. And since anyway terminate is a bad idea, this needs to be redesigned. Thomas: I can't see how locking a mutex can work in a single-threaded case (there are no threads in your code; you seem to rely on the fact that Qt uses a thread internally in QHostInfo? That seems dangerous...). Thiago and I came up with a design like this: * a single thread that makes async lookups. It's never blocked, it can always almost immediately read new requests from a queue and start them. * each request is encapsulated in a class that has the QString but also a QSemaphore. * the main thread can block using a timeout (QSemaphore::tryAcquire(timeout)) * the request class is stored using a shared pointer, so that it's only deleted when neither the main thread nor the worker thread need it anymore [otherwise the deletion is a problem, in the timeout case vs the normal case] -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).