[GSoC] UPnP progress report week 3

[Nikhil Marathe]

On 6/6/10, Nikhil Marathe <nsm.nikhil at gmail.com> wrote:
> On 6/5/10, Maximilian Kossick <maximilian.kossick at googlemail.com> wrote:
>> I don't think so.
>>
>> I remember a few thread on kde-devel about running threads in
>> kioslaves. You could start a special thread in your kioslave to
>> perform your monitoring.
>>
>
> Thanks for the heads up Maximilian. Actually one of those threads was mine
> :)
> When I was experimenting in March, a threaded implementation
> experiment had driven me crazy and so I kind of didn't want to do
> that, even though that would solve the issue.
>
> Now after reading some docs and being careful, I have a working
> threaded implementation at the same level as the non threaded
> kioslave. And it only took a day. Its not public yet, but after a few
> touches it will replace the current slave.
>
> Regards,
> Nikhil
>

Ok, the problem has nothing to do with threads. It seems the *entire
slave process* is put into a sleep state by the scheduler so that it
doesn't matter how many threads are running until the slave is woken
up again. The solution is to keep the slave in busy wait so that it
isn't put into sleep. But this would require the following to happen

Main Thread invokes method on Control Point thread
Control Point Thread does voodoo and hands back results using signals/slots
MainThread notifies the slave mechanism of the results using
KIO::SlaveBase::listEntry() and friends.
Main Thread then calls finish(), and here is the crucial part

Just *before* finish() is called, I would like to have the Control
Point thread begin a busy wait which *does not* block the entire
process. IE. it starts busy wait but control returns immediately to
the Main Thread which calls finish and hopefully the process isn't
taken off the CPU.

I can't think of any way to do this. I have tried various combinations
of QueuedConnection slots and so on, but none work. Any help would be
great.

Nikhil