Hello,<div><br><div><div>Since looks like the item 3 (below) it's a general Solid issue (regarding with the backends management) I think the rest of the list should be aware of it...</div><div><br></div><div><i>3) Due to the use of a QThreadStorage on the backends manager, a new<br>
HControlPoint is created for every UPnPDeviceManager created. This may<br>cause issues where in the thread affinity decides which HCP is queried<br>and which HCP monitors and so on, leading to wrong results. Every user<br>
of Solid should have only one HControlPoint, irrespective of the<br>number of threads.</i></div><div><br></div><div>Thanks, Nikhil, I'm working on the UPnP backend issues you pointed out.</div><div><br></div><div>Regards,<br clear="all">
--<br>Paulo Rômulo Alves Barros<br>MSc. Candidate in Computer Science<br>Embedded Systems and Pervasive Computing Lab<br><a href="http://embedded.ufcg.edu.br/indexen.html" target="_blank">http://embedded.ufcg.edu.br/indexen.html</a><br>
<br>
<br><br>
<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Nikhil Marathe</b> <span dir="ltr"><<a href="mailto:nsm.nikhil@gmail.com" target="_blank">nsm.nikhil@gmail.com</a>></span><br>
Date: Sun, Jul 25, 2010 at 8:19 AM<br>Subject: HUpnp, Solid and changes in the slave<br>To: Paulo Rômulo <<a href="mailto:p.romuloo@gmail.com" target="_blank">p.romuloo@gmail.com</a>><br>Cc: Kevin Ottens <<a href="mailto:ervin@kde.org" target="_blank">ervin@kde.org</a>>, Bart Cerneels <<a href="mailto:bart.cerneels@kde.org" target="_blank">bart.cerneels@kde.org</a>><br>
<br><br>Hi,<br>
<br>
Over the past few days I've been grappling with various issues related<br>
to HUpnp support in Solid and using it in a kioslave and things like<br>
that. I have a few comments about the Solid code, and changes I've<br>
made in the slave and how Solid UPnP will fit into my project.<br>
<br>
Solid UPnP backend changes<br>
=================<br>
<br>
There are some issues in the current code which should be fixed<br>
immediately since it is not the right way to use the HUpnp library and<br>
will lead to crashes or errors.<br>
<br>
1) UPnPDeviceManager::allDevices(). The call to scan is treated as if<br>
it is blocking. HControlPoint::scan() is non-blocking. Which means any<br>
devices detected by the scan will not be reported in rootDevices()<br>
since they haven't been detected when that code is reached. The scan<br>
should be abandoned, because allDevices() should return what the HCP<br>
knows about. HCP automatically scans and stores internally.<br>
<br>
2) UPnPDevice destructor SHOULD NOT delete the internal HDeviceProxy,<br>
that is managed by the HCP.<br>
<br>
3) Due to the use of a QThreadStorage on the backends manager, a new<br>
HControlPoint is created for every UPnPDeviceManager created. This may<br>
cause issues where in the thread affinity decides which HCP is queried<br>
and which HCP monitors and so on, leading to wrong results. Every user<br>
of Solid should have only one HControlPoint, irrespective of the<br>
number of threads.<br>
<br>
4) UPnPDeviceManager::rootDeviceOffline() Again a device is being<br>
explicitly removed when it is not required. This won't cause crashes<br>
or anything but seems redundant.<br>
<br>
The slave<br>
======<br>
I am dropping Cagibi and Solid support from the slave. The slave has<br>
to perform actions on the remote devices and so requires a<br>
HControlPoint anyway. This HCP is perfectly capable of detection and<br>
so it is a double effort to use either Cagibi or Solid to first<br>
confirm the device is up and then make the HCP scan for it and<br>
initialize its internal device model. So in the most recent commit of<br>
kio_upnp_ms, I have no external dependencies on these 2.<br>
<br>
The Amarok collection<br>
=============<br>
Staying true to Solid's purpose of device detection and notification,<br>
the Amarok UpnpCollectionFactory WILL use Solid. This way it can see<br>
devices coming or going and create appropriate Collection instances.<br>
<br>
I saw in the post Akademy notes that Solid is aiming for UPnP<br>
integration in 4.7. In my opinion that is too late. I would like to<br>
aim for 4.6, because Cagibi is not extremely high quality and fails to<br>
detect a lot of devices. It would be foolish to rely on it when we<br>
have a better alternative. I understand that Solid being a core<br>
library has to make decisions keeping things like Binary Compatibility<br>
in mind, but I am willing to spend time on the backend to make it<br>
stable and tested if that is the case.<br>
<br>
With Amarok aiming for UPnP support as soon as possible, it would be<br>
great if Solid can provide the required support.<br>
<br>
@Bart: I've fixed the slave, no crashes anymore, HUpnp does have a<br>
bug, in the sense that it calls processEvents() once before exiting<br>
and bad code elsewhere may make it crash too. Tuomo is aware and<br>
thinking of a solution.<br>
<br>
@Paulo: The above thing about HUpnp crashing while processing events<br>
might affect you, but it happens in a not easily reproducible<br>
situation. I think if you did constant tests with it, you might be<br>
able to help him pinpoint the reason.<br>
<br>
Thanks,<br>
Nikhil<br>
<font color="#888888"><br>
--<br>
Support open formats.<br>
Don't send me files in proprietary formats like .doc, .xls, .ppt.<br>
</font></div><br></div></div></div>