| Summary: |
consider having PendingOperation ref itself and its parent until finished |
| Product: |
Telepathy
|
Reporter: |
Simon McVittie <smcv> |
| Component: |
tp-qt | Assignee: |
Olli Salli <ollisal> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
Telepathy bugs list <telepathy-bugs> |
| Severity: |
normal
|
|
|
| Priority: |
medium
|
CC: |
andrunko
|
| Version: |
git master | |
|
| Hardware: |
Other | |
|
| OS: |
All | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
PendingOperation and its subclasses don't guarantee to stay alive until the operation finishes. The equivalent constructs in the GLib world (GAsyncResult, TpProxyPendingCall etc.) tend to keep a reference to themselves and the object they belong to for the duration of the call, for greater predictability. We should consider doing the same in telepathy-qt4. I haven't investigated whether there are precedents either way in Qt/KDE. 13:35 < albanc> smcv, andrunko : I don't keep a reference on the PendingChannelRequest object returned by Tp::Account->ensureChannel. I guess the object is released too soon. I also have this warning: 13:35 < albanc> Telepathy-Qt4 (version 0.3.4) WARNING: Tp::PendingOperation(0x326b40) still pending when it was deleted - finished will never be emitted 13:35 < smcv> albanc: yeah don't do that :-P ... 13:38 < smcv> andrunko: would it make sense for the PendingOperation to keep itself alive artificially until it finishes? 13:39 < smcv> andrunko: (a GAsyncResult keeps itself and its parent object alive) 13:40 < andrunko> smcv, maybe, the problem is that if we have a bug and nobody calls finish we will leak 13:41 < smcv> andrunko: welcome to reference counting. I personally think a leak is less bad than objects disappearing before they ought to 13:41 < smcv> and it's a bug either way