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