We'd like to offer a way for developers to safely do asynchronous instantiations
of COM objects. This patch adds a static CreateInstance method to mscom::EnsureMTA
that facilitates this under certain conditions (as outlined in the comments).
To help ensure that this is as safe as possible, we return a MozPromise that,
once resolved, produces an AgileReference that may then be passed between
threads, and may then be resolved when a specific thread needs to access the
interface.
Differential Revision: https://phabricator.services.mozilla.com/D44519
--HG--
extra : moz-landing-system : lando
The new StaticLocalAutoPtr smart pointer has a trivial destructor, so we will
either properly clean up this data or leak it on process shutdown. Either way,
we will not destroy it in a way that the underlying type does not support.
Differential Revision: https://phabricator.services.mozilla.com/D40842
--HG--
extra : moz-landing-system : lando
The new StaticLocalAutoPtr smart pointer has a trivial destructor, so we will
either properly clean up this data or leak it on process shutdown. Either way,
we will not destroy it in a way that the underlying type does not support.
Differential Revision: https://phabricator.services.mozilla.com/D40842
--HG--
extra : moz-landing-system : lando
Until now we asserted that EnsureMTA was being called from the main thread
unless the current thread was already in the MTA.
This patch makes MTA thread initialization thread-safe by using a C++11
"magic static," thus allowing EnsureMTA to be safely invoked from any thread.
Differential Revision: https://phabricator.services.mozilla.com/D38422
--HG--
extra : moz-landing-system : lando
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
