View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006734 | MMW v4 | Other | public | 2010-11-23 09:35 | 2011-07-18 23:33 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Platform | Windows | OS | 7 | OS Version | - |
| Product Version | 4.0 | ||||
| Target Version | 4.0 | ||||
| Summary | 0006734: UPnP starts >10 threads | ||||
| Description | Inspection by Process Explorer shows that UPNp.dll starts at least 10 threads. We should review whether this is really necessary and hopefully to reduce this. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Today, I studied the Platinum sources slightly and I found out that for the client (Control point) following 5 tasks seem to be running pernamently: PLT_SsdpListenTask (the ssdp listener) PLT_HttpServerListenTask (HttpServer listens on an IP address) PLT_CtrlPointHouseKeepingTask PLT_SsdpSearchTask (for address 192.168.2.4) PLT_SsdpSearchTask (for address 127.0.0.1 - loopback) and if you enable and configure a server in options then there are further several tasks running, but only about 5 of them are running pernamently: PLT_HttpServerListenTask (task to listen) PLT_SsdpDeviceAnnounceTask PLT_SsdpDeviceSearchResponseTask (task to respond to the request) PLT_CtrlPointGetDescriptionTask (task to retrieve the description) PLT_CtrlPointGetSCPDTask (one single task to fetch all scpds one after the other) PLT_HttpServerTask PLT_CtrlPointSubscribeEventTask I think it wouldn't be a good idea to do something about it by our own, because Sylvain is still developing Patinum and it would be time consuming to apply our source changes into his new sources everytime an upgrade is available. The better solution would be to contact Sylvain and ask him whether there really must be so many tasks running pernamently. Note that by default no such a task is running, because MediaMonkey inits the UPnP only when: User expands 'UPnP Severs' node OR User has configured an UPnP server or allows control of MediaMonkey player via UPnP in Options|Media Sharing otherwise UPnP isn't initialized at all |
|
|
Feedback from Sylvain: So the number of threads is controlled by the class PLT_TaskManager. The default is there's no limit, however you can specify a limit in the constructor. When there's a limit, tasks (thread) will wait and not be scheduled (started) until old tasks are finished. If there are long running tasks, this could block for a long time. Because some tasks are long running (meaning they never finish until the upnp is shut down), some classes have their own TaskManager. This is the case of PLT_DeviceHost, PLT_CtrlPoint. Additionally, the PLT_HttpServer has its own TaskManager so that it can handle incoming requests independently. By default, the PLT_HttpServer doesn't limit the number of threads either. The reason is that it supports HTTP 1.1 with request pipelining so if the client doesn't close the connection upon receiving a HTTP response, the task needs to stay running for at least 30 secs in case the client is sending another request. This means that you could easily be reaching the maximum of connections (threads) fast. However we could lower the 30 secs to less. The PLT_DeviceHost on top of its own PLT_TaskManager, has a PLT_HttpServer but limit the number of tasks for it to 100 (5 on the XBox). You can certainly lower that number. The PLT_CtrlPoint on top of its own PLT_TasManager, also has a PLT_HttpServer (the m_EventHttpServer). This one somehow doesn't have a limit. It could use one if needed. Finally, the PLT_UPnP also has its own PLT_TaskManager but it only runs 1 task (m_SsdpListenTask). So to recap PLT_DeviceHost: 2 TaskManagers (1 is limited to 100) PLT_CtrlPoint: 2 TasksManagers (unlimited) PLT_UPnP: 1 TaskManager (unlimited but only 1 task running) One other thing that could be improved is to keep a true ThreadPool where threads are pre-allocated, running without tasks attached or at least kept running once tasks are finished. |
|
|
Ludek, please review whether we can use the info from Sylvain to configure it so that not so many threads are started, without any degradation of performance. |
|
|
As discussed over Skype, the problem isn't in the unlimited amount of threads, but rather in the amount of the long running tasks (meaning they never finish until the upnp is shut down), but we aren't going to do anything about it, it is up to Sylvain. |
|
|
Closed until New reports |
