Summary says it all. /be
Seems to work, browsing with it. /be
Attachment #491748 - Flags: review?(gal)
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
I don't think that's a full fix, don't we need a similar check in ConstructSlimWrapper? Also, can we just remove XPC_CHECK_WRAPPER_THREADSAFETY if it'll always be defined anyway?
(In reply to comment #4) > I don't think that's a full fix, don't we need a similar check in > ConstructSlimWrapper? Peter, can you file this one? Even better if you or a slimwrapper guru can fix. I'm overcommitted elsewhere. > Also, can we just remove XPC_CHECK_WRAPPER_THREADSAFETY if it'll always be defined anyway? Minimal change at this stage. /be
So if I understand correctly, this prevents creating new wrappers for main-thread-only objects on a non-main thread, right? If a wrapper for such an object is in the scope of a runnable closure passed to the background thread then this patch doesn't help, as far as I can tell. It also doesn't help if the problem is the creation and/or refcounting of the C++ object, right? Because all that happens long before we try to create a wrapper for it...
You need to log in before you can comment on or make changes to this bug.