[PATCH] KIO::SlaveBase and the event loop

[Sebastian Trüg]

On Tuesday 15 July 2008 17:13:18 Thiago Macieira wrote:
> Sebastian Trüg wrote:
> >On Tuesday 15 July 2008 14:45:54 Thiago Macieira wrote:
> >> Sebastian Trüg wrote:
> >> >> I tried implementing that last year and gave up.
> >> >
> >> >what were the problems?
> >>
> >> Well, my plan was a bit more ambitious. I wanted all ioslaves to run
> >> inside an event loop. The KIO::Connection would be used in in
> >> readyRead() slot handlers instead of waitFor* style functions as it is
> >> right now.
> >>
> >> It was too much work for too little gain.
> >
> >one more question: do you know if there is a problem with calling the
> >SlaveBase methods such as listEntry from another thread? Do I have to
> > handle that through QueuedConnections?
>
> QueuedConnection implies an event loop to receive them, but not to send.
> If you want to use that, you need to start an event loop in the other
> thread. The way that you phrased your question, I understand that you
> meant calling the main thread from the auxiliary D-Bus thread. So you go
> back to your original issue: an event loop in the main thread.
>
> However, let me try to understand the issue at hand: you have an ioslave
> that retrieves data via D-Bus and said data comes via D-Bus signals.
> (That would explain why you need an event loop)
>
> If that is so, then you can just start a QEventLoop inside your listDir()
> reimplementation. Once the data has finished transferring, you don't need
> to handle the D-Bus socket anymore.

that is what I do anyway. But the problem is a bit more twisted:

> You *only* need a thread if you need to react to external D-Bus signals
> outside of an IOSlave call. (Those could be things like connection
> maintenance, watching for something, etc.)

exactly. So this is what I do now and it works with one drawback:

I create a local event loop in the listDir method and execute it after 
starting my thread that does all the dbus communication. DBus signals come in 
via a queued connection and are handled in the main thread (they create 
listEntry calls). Once the initial listing is done (search) I disconnect the 
dbus signals and reconnect them directly. That is because once my local event 
loop is done I still need to get the dbus signals to update my internal state 
and emit KDirNotify signals.
It works but with a rather bis delay for the update signals that are to be 
delivered directly. I don't really understand that since my thread runs its 
own event loop.

I hope this was not too confusing. ;)

Cheers,
Sebastian