| Anonymous | Login | Signup for a new account | 10-09-03 02:48 CEST |
| Main | My View | View Issues | Change Log | Roadmap | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||
| 0002232 | [XMMS2] clientlib | major | always | 09-06-12 07:50 | 10-02-20 15:09 | ||
| Reporter | p00ya | View Status | public | ||||
| Assigned To | nano | ||||||
| Priority | normal | Resolution | fixed | ||||
| Status | resolved | Product Version | 0.6 DrM | ||||
| Summary | 0002232: CF clientlib spins after xmms2 quit | ||||||
| Description |
After xmms2d has quit, there is no way to remove the event sources from the CoreFoundation runloop. Consequently, the runloop ends up spinning without making any client code callbacks. This uses an undesirable waste of CPU cycles in the client. To reproduce (after 0002191 patch is applied): start xmms2d. From client code: xmmsc_connect optionally register some async results xmmsc_setup_with_cf quit xmms2d, and optionally have the client xmmsc_unref the connection watch CPU usage of client increase in top(1) or similar. The attached patch provides the client with some state on init that can be passed back to the shutdown function to deregister the runloop source. It's passed as an extra parameter. I have renamed the exported functions to be consistent with the other clientlibs. Note that but this will NOT cause a compatibility issue: the declaration was wrong to start off with. See 0002191 which demonstrates that the CF clientlib in its current state is broken. |
||||||
| Additional Information | |||||||
| Tags | No tags attached. | ||||||
| GIT commit id | 3ab1c686d6aa3a5e98b0c690da62f1c42566d837 | ||||||
| Has patch | Yes, needs review | ||||||
| Attached Files |
 xmms2-cf-shutdown.patch [^] (1,971 bytes) 09-06-12 07:50 |
||||||
|
|
|||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
|
Notes |
|
|
(0003848) p00ya (reporter) 09-06-12 07:51 |
oops, meant to have severity minor |
|
(0003858) nano (manager) 09-06-28 09:33 |
Isn't the patch missing something, seems like xmmsc_mainloop_cf_shutdown is never called? |
|
(0003860) p00ya (reporter) 09-06-28 09:40 |
uh, you have to call it manually from the client (presumably like xmmsc_mainloop_gmain_shutdown?), that's why xmmsc_mainloop_cf_shutdown isn't static. I suppose if xmms had some way to add hooks to a connection unref you could do that, but that doesn't seem to be the pattern in, say, xmmsclient-glib.c. |
|
(0003861) nano (manager) 09-06-28 10:00 |
fixed in my tree, awaiting merge |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 09-06-12 07:50 | p00ya | New Issue | |
| 09-06-12 07:50 | p00ya | File Added: xmms2-cf-shutdown.patch | |
| 09-06-12 07:50 | p00ya | Has patch | => Yes, needs review |
| 09-06-12 07:51 | p00ya | Note Added: 0003848 | |
| 09-06-28 09:33 | nano | Note Added: 0003858 | |
| 09-06-28 09:33 | nano | Status | new => feedback |
| 09-06-28 09:40 | p00ya | Note Added: 0003860 | |
| 09-06-28 10:00 | nano | Note Added: 0003861 | |
| 09-06-28 14:17 | nano | GIT commit id | => 3ab1c686d6aa3a5e98b0c690da62f1c42566d837 |
| 09-06-28 14:17 | nano | Status | feedback => resolved |
| 09-06-28 14:17 | nano | Fixed in Version | => 0.7 DrN |
| 09-06-28 14:17 | nano | Resolution | open => fixed |
| 09-06-28 14:17 | nano | Assigned To | => nano |
| 09-06-28 14:17 | nano | Target Version | => 0.7 DrN |
| 10-02-20 11:38 | nano | Target Version | 0.7 DrN => 0.8 DrO |
| 10-02-20 15:07 | nano | Target Version | 0.8 DrO => 0.7 DrN |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
