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

List:       kde-devel
Subject:    Re: KIO::listDir() freezes in multi-threaded KioFuse due to timer
From:       Vlad Codrea <vladc6 () yahoo ! com>
Date:       2007-10-14 17:59:36
Message-ID: 820930.72216.qm () web54402 ! mail ! yahoo ! com
[Download RAW message or body]

--- Thiago Macieira <thiago@kde.org> wrote:
> Vlad Codrea wrote:
> >KioFuse freezes and gives the following warning when Fuse is
> allowed
> >to create a separate thread for every filesystem operation. The
> first
> >readdir() attempt succeeds, but the freeze and warning appear
> >consistently on the second readdir() attempt:
> 
> Solution: use KIO from the GUI thread only.

This seems to be an artificial limitation, since KIO and the GUI don't
have much in common. There are apps, like KioFuse, that need file
access but not a GUI. I thought that separating the GUI and non-GUI
parts of KIO would have gotten rid of the GUI-thread limitation
(http://websvn.kde.org/?view=rev&revision=632925).

I can modify KioFuse to use KIO from the main thread, but that will
add complexity to the program. I wonder if it would be better for me
to try to make KIO usable from non-GUI threads, especially since other
apps might need this, too. Just to be clear, I'm not talking about
making KIO threadsafe (ie. using the same ListJob instance in multiple
threads), but simply being able to create/use a ListJob instance in a
non-GUI worker thread. Do you think this is feasible and worthwhile?

Thanks,
Vlad


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]