[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Replacement for processEvents() call within while loop
From:       Vlad <vladc6 () yahoo ! com>
Date:       2007-09-30 4:39:04
Message-ID: 168402.90603.qm () web54406 ! mail ! yahoo ! com
[Download RAW message or body]

Hi,

--- David Faure <faure@kde.org> wrote:
> On Thursday 27 September 2007, Vlad wrote:
> > One way to get around it would
> > be to make done() emit a signal. The problem is that, once the
> helper
> > is done, execution must revert to the function that currently
> contains
> > the while loop 
> 
> QEventLoop can do this. Connect to your signal, call
> eventLoop.exec(QEventLoop::ExcludeUserInputEvents)
> and in your slot call eventLoop.quit(), so that the control goes
> back to the method that called exec.

Thank you very much! Your suggestion works as a drop-in replacement
for the while loop. However, it seems that multiple userspace apps
can't access remote files at the same time. Currently, if a directory
takes a long time to be accessed (simulated by a sleep(20) call in
ListJobHelper::receiveEntries), all new requests to kioFuseReadDir are
stalled until the 20 seconds is up. This undesired behavior is shared
by the while loop, so it's not a regression.

I'm thinking sleep() is not a good simulator of KIO slave latency
because it freezes KioFuse entirely. Any suggestions on a better way
to simulate a slow network?

Thanks again,
Vlad

PS: The KDE4 port of KioFuse is now in
http://websvn.kde.org/trunk/playground/libs/kiofuse .


      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]