In our current extension, we have code like the following to ensure
that code is run on the UI thread. The code below is an over-
simplification of the actual algorithm, just trying to show use
pattern. Decision was made to use this pattern based on
http://www.mozilla.org/projects/xpcom/Proxies.html and ease of coding.
In FF2, nsIProxyObjectManager.h defines appropriate macros for being
able to find the proxy manager (NS_XPCOMPROXY_CONTRACTID) or also
gives visibility to NS_GetProxyForObject().
--- example code begin
int MyObject::notify( unsigned long cmd ) {
nsresult rv;
nsCOMPtr<nsIProxyObjectManager> spProxyManager;
spProxyManager = do_GetService(NS_XPCOMPROXY_CONTRACTID, &rv);
nsCOMPtr<IMyObject> prox;
spProxyManager->GetProxyForObject(
NS_UI_THREAD_EVENTQ,
NS_GET_IID(IMyObject),
(IMyObject*)this,
PROXY_ASYNC | PROXY_ALWAYS,
(void**)&prox );
prox->processCommand( cmd );
}
--- example code end
In FF3, now it appears that these are trying to be "hidden" (use is
discouraged?)
- NS_XPCOMPROXY_CONTRACTID now defined in nsXPCOMCIDInternal.h
- NS_GetProxyForObject is now hidden behind #ifdef
MOZILLA_INTERNAL_API
In FF3, is there a new preferred way for communicating from worker
threads to the main thread? If so, is there a sample extension that
is already using this model?