Closed
Bug 599970
Opened 14 years ago
Closed 14 years ago
Add GetInterface for nsIEventTarget on Connection
Categories
(Core :: SQLite and Embedded Database Bindings, defect)
Core
SQLite and Embedded Database Bindings
Tracking
()
RESOLVED
FIXED
mozilla2.0b9
People
(Reporter: sdwilsh, Assigned: sdwilsh)
References
Details
(Whiteboard: [fixed-in-places])
Attachments
(1 file)
4.92 KB,
patch
|
asuth
:
review+
|
Details | Diff | Splinter Review |
It could be useful for consumers to post an event to the async thread. However, this would be a *highly* advanced operation that most consumers wouldn't need, so we should make Connection implement nsIInterfaceRequester, and when it is asked for an nsIEventTarget, go ahead a return the background thread.
Assignee | ||
Comment 1•14 years ago
|
||
Patch I have needs to be applied on top of bug 596970 (not a typo, it is in fact 3000 less than this bug)
Depends on: 596970
Assignee | ||
Updated•14 years ago
|
Attachment #481060 -
Flags: review?(bugmail)
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review asuth]
Comment 3•14 years ago
|
||
Comment on attachment 481060 [details] [diff] [review]
v1.0
I presume "*highly* advanced operation" === "do not document this on the IDL; for use only by those proficient in precisely shooting between their toes"?
I'm going to treat this as a warranty voiding operation. Specifically, this adds some potentially new situations where a reference can go out of scope on the async thread that are not already covered but I'm not going to look into those. That's on whomever writes the code that dispatches to the async thread...
Attachment #481060 -
Flags: review?(bugmail) → review+
Assignee | ||
Comment 4•14 years ago
|
||
(In reply to comment #3)
> I presume "*highly* advanced operation" === "do not document this on the IDL;
> for use only by those proficient in precisely shooting between their toes"?
Yup.
> I'm going to treat this as a warranty voiding operation. Specifically, this
> adds some potentially new situations where a reference can go out of scope on
> the async thread that are not already covered but I'm not going to look into
> those. That's on whomever writes the code that dispatches to the async
> thread...
Yeah, there were a few threadsafety things I thought about defending against, but then I realized that doing this means you damn well better know what you are doing or you will go boom somewhere anyway.
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs review asuth] → [has review]
Assignee | ||
Comment 5•14 years ago
|
||
Whiteboard: [has review] → [fixed-in-places]
Comment 6•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b9
Updated•6 months ago
|
Product: Toolkit → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•