KIO from inside a parsejob?

[Andreas Pakulat]

On 15.07.09 18:14:40, Milian Wolff wrote:
> Andreas Pakulat wrote:
> >On 15.07.09 16:52:04, Milian Wolff wrote:
> >>Andreas Pakulat wrote:
> >>>On 15.07.09 07:39:49, Niko Sams wrote:
> >>>>On Wed, Jul 15, 2009 at 01:48, Milian Wolff<mail at milianw.de> wrote:
> >>>>>Am Dienstag, 14. Juli 2009 22:43:19 schrieb Milian Wolff:
> >>>>>>Hey guys,
> >>>>>>
> >>>>>>could it be that KIO must not be accessed from a parsejob? Look at that, I
> >>>>>>can't explain it:
> >>>>>>
> >>>>>>http://mwolff.pastebin.com/f4e26ba49
> >>>>>>
> >>>>>>I try to fix the includebuilder for PHP and remote projects. My code now:
> >>>>>>
> >>>>>>http://mwolff.pastebin.com/f6b676fc0
> >>>>>>
> >>>>>>Here's the debug output on the console:
> >>>>>>http://mwolff.pastebin.com/f130f444b
> >>>>>>
> >>>>>>What's that about QPair's?! Is my build fubar? Help!
> >>>>>It's definitly the KIO::NetAccess::exists(). If I comment that out everything
> >>>>>seems to work fine.
> >>>>>
> >>>>>Niko: Have you ever tested that? Or did it work for you back then?
> >>>>I never tested with non-local files.
> >>>>
> >>>>I think we can't use KIO in a background thread (?).
> >>>I suggest asking on kde-core-devel (unless you've examined kio's code ;)
> >>Just asked in #kde-devel and pinotree said KIO is not threadsafe. So
> >>yeah, I think I'll have to remove that code...
> >>
> >>Niko, I'd say we change the whole logic to the following:
> >
> >Why not make your code using kio threadsafe then? Even if you cannot use
> >kio across threads, you can make sure that you're using it only from one
> >thread. Even if you can use kio just from the GUI thread you can still
> >do this.
> 
> Can you tell me how? Or give me some pointers to the documentation.

Not without digging into your source code :P Basically however, if you
hit a place in your code where you need to fetch the contents of a file
via KIO (or list a dir etc.) and you're running in a non-GUI thread
(i.e. currentThread != qApp->thread() ) you could send a signal thats
connected to some GUI-thread code you have that executes KIO and returns
the results somehow via another signal. The non-GUI thread then simply
blocks/waits for the other signal.

I'm doing something similar in the subversion plugin when asking the
user for his password. The code for svn commit runs in a background
thread and I get notified from the svn-lib that it needs credentials,
then it sends a signal and waits on a semaphore (i.e. the background
thread blocks). In the GUI thread a dialog is shown, the user puts his
credentials. At this point the code in the GUI thread sets the needed
data onto the background-thread object and then unlocks the semaphore.

See svnjobbase.cpp (askForLogin) and svninternaljobbase.cpp
(initBeforeRun and contextGetLogin).

Obviously this increases complexity of your classes and interoperations
between them, so if the other option is a lot easier to implement and
works "well enough" feel free to go that route.

Andreas

-- 
Just to have it is enough.