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

List:       kde-devel
Subject:    Re: Unexpected behaviors in KIO::FileJob async file access
From:       Vlad Codrea <vladc6 () yahoo ! com>
Date:       2007-12-21 17:12:01
Message-ID: 885114.30788.qm () web54403 ! mail ! yahoo ! com
[Download RAW message or body]

--- Thiago Macieira <thiago@kde.org> wrote:
> Vlad Codrea wrote:
> >Any ideas what is causing these behaviors and how to fix them?
> 
> The ioslaves are causing this behaviour. Since each ioslave is
> different 
> from the next, your code has to be resistant to those issues.

I did make KioFuse resistant to unexpected behaviors #1 and #2 by
ignoring extraneous FileJob::data() and FileJob::position() signals,
respectively. However, I don't see how to bypass behavior #3, where
KioFuse just freezes while expecting a FileJob::data() signal that
never arrives.

Strangely enough, I've discovered that using another FileJob instance
causes the frozen FileJob::data() signal to finally be called.
Unfortunately, the new FileJob instance is now itself frozen until
another FileJob instance is used.

Regarding the differences between ioslaves: so far I've only been
using the file:// ioslave, and the FileJob behaviors are erratic when
using the exact same ioslave, on the exact same file.  Sometimes the
::position() signal is called twice, sometimes only once. Sometimes
the ::data() signal is called twice, sometimes not at all (until
kickstarted).

Are there any apps beside Phonon and KioFuse using FileJob
(http://lxr.kde.org/ident?i=FileJob)? I'd like to see how those apps
are handling these unexpected behaviors, as Phonon doesn't seem to be
working around them.

Thanks,
Vlad


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]