Review Request: Replace thread usage with local event loop in kio/kio/hostinfo.cpp

[Dawit A]

On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander <zander at kde.org> wrote:
> On Monday 08 August 2011 21.02.02 Dawit A wrote:
>> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander <zander at kde.org> wrote:
>> > On Monday 08 August 2011 18.35.13 Dawit A wrote:
>> >> #2. The original functions in this class were non-blocking. It is only
>> >> the new function I added that is a blocking call. And that is required
>> >> because of the need for a timeout when doing name lookups from the
>> >> urifilter plugins. Thos plugins perform a job that is time critical
>> >> and as such cannot be impeded by name lookups that will take too long
>> >> and hence the need for a timeout. If QHostInfo offered such interface,
>> >> then there will be no need for the newly added functions.
>> >
>> > Maybe naive; but would it not be simpler to wrap the Qt method like this?
>> >
>> >  const int id = QHostInfo::lookupHost ( hostname, receiver,  slot);
>> >  QTimer::singleshot(timeout, QHostInfo::abortHostLookup (id );
>>
>> eh ? The version of QHostInfo::lookupHost you used above is non
>> blocking so the entire function becomes a non-blocking function which
>> is not what we want.
>
> In Qt (networking) stuff is non-blocking, which carries over to KDELibs using
> non-blocking calls.
> So by my reading we *do* want it to be non-blocking.
> The main reason I see to use blocking calls  is because they are easier to use
> as a programmer as they allow you to avoid having an extra slot to handle the
> callback.
> Am I missing a reason for this case?

Yes. The uri filter plugins that are the primary users of this new
function require a synchronous function call or they would all have to
implement this syncing part individually for themselves.