MozillaWiki

XPCOM:nsIThreadManager: Difference between revisions

Page Discussion

XPCOM:nsIThreadManager (view source)

Revision as of 07:03, 5 May 2006

132 bytes removed ,  5 May 2006
m
→‎nsRunnable
 
(10 intermediate revisions by the same user not shown)
Line 6: Line 6:
  interface nsIThreadManager : nsISupports {
  interface nsIThreadManager : nsISupports {
   /**
   /**
     * Create a new named thread (a global, user PRThread).  If the name is
     * Create a new thread (a global, user PRThread).  Currently, flags is
     * non-empty, then the name of the thread must be unique.  Specifying an
     * an unused parameter, that must be 0.
    * empty name results in an anonymous thread that cannot be found later on
    * using the getThread method.
     */
     */
   nsIThread newThread(in ACString name);
   nsIThread newThread(in unsigned long flags);
   
  /**
    * Find a named thread.  If no thread exists by the given name, then null
    * is returned.
    */
  nsIThread getThread(in ACString name);
    
    
   /**
   /**
Line 73: Line 65:
  [scriptable, uuid(...)]
  [scriptable, uuid(...)]
  interface nsIThread : nsIEventTarget {
  interface nsIThread : nsIEventTarget {
  /**
    * Returns the name of the thread, which may be empty if this thread is
    * anonymous.
    */
  readonly attribute ACString name;
   
   /**
   /**
     * Returns the PRThread object corresponding to this nsIThread.
     * Returns the PRThread object corresponding to this nsIThread.
     */
     */
   [noscript] PRThread getPRThread();
   [noscript] readonly attribute PRThread PRThread;
    
    
   /**
   /**
Line 100: Line 86:
   /**
   /**
     * Process the next event.  If there are no pending events, then this
     * Process the next event.  If there are no pending events, then this
     * method will wait until an event is dispatched to this thread.  This
     * method may wait -- provided mayWait is true -- until an event is  
    * method is re-entrant but may only be called if this thread is the
    * dispatched to this thread.  This method is re-entrant but may only be
     * current thread.
    * called if this thread is the current thread.
     *
    * @return A boolean value that is "true" if an event was processed.
     */
     */
   void processNextEvent();
   boolean processNextEvent(in boolean mayWait);
  };
  };
=== nsIThreadInternal ===
=== nsIThreadInternal ===
  [scriptable, uuid(...)]
  [scriptable, uuid(...)]
Line 151: Line 140:
     *        Indicates whether or not the method is allowed to block the calling
     *        Indicates whether or not the method is allowed to block the calling
     *        thread.  For example, this parameter is false during thread shutdown.
     *        thread.  For example, this parameter is false during thread shutdown.
    * @param recursionDepth
    *        Indicates the number of calls to ProcessNextEvent on the call stack
    *        in addition to the current call.
     */
     */
   void onProcessNextEvent(in nsIThreadInternal thread,
   void onProcessNextEvent(in nsIThreadInternal thread, in boolean mayWait,
                           in boolean mayWait);
                           in unsigned long recursionDepth);
  };
  };


Line 207: Line 199:
   * Create a new thread.
   * Create a new thread.
   *
   *
   * @param name
   * @param result
   *        The name of the thread (must be unique) or the empty string to
   *        The resulting nsIThread object.
  *        create an anonymous thread.
   * @param event
   * @param event
   *        The initial event to run on this thread.  This can be null.
   *        The initial event to run on this thread.  This can be null.
  * @param result
  *        The resulting nsIThread object.
   */
   */
  NS_METHOD NS_NewThread(const nsACString &name, nsIRunnable *event,
  NS_METHOD NS_NewThread(nsIThread **result, nsIRunnable *event);
                        nsIThread **result);
   
   
  /**
  /**
Line 233: Line 221:
   */
   */
  NS_METHOD NS_GetMainThread(nsIThread **result);
  NS_METHOD NS_GetMainThread(nsIThread **result);
 
/**
  * Get a reference to the thread with the given name.
  *
  * @param name
  *        The name of the requested thread.  Must be non-empty.
  * @param result
  *        The resulting nsIThread object.
  */
NS_METHOD NS_GetThread(const nsACString &name, nsIThread **result);
   
   
  /**
  /**
Line 296: Line 274:
   
   
  already_AddRefed<nsIThread> do_GetMainThread();
  already_AddRefed<nsIThread> do_GetMainThread();
&nbsp;
already_AddRefed<nsIThread> do_GetThread(const nsACString &name);


=== nsRunnable ===
=== nsRunnable ===
Line 316: Line 292:
Dispatching <code>MyEvent</code> is then as simple as:
Dispatching <code>MyEvent</code> is then as simple as:


nsCOMPtr<nsIThread> thread = do_GetCurrentThread();
NS_ENSURE_STATE(thread);
&nbsp;
  nsCOMPtr<nsIRunnable> event = new MyEvent();
  nsCOMPtr<nsIRunnable> event = new MyEvent();
  NS_ENSURE_STATE(event);
  rv = NS_DispatchToCurrentThread(event);
  &nbsp;
  NS_ENSURE_SUCCESS(rv, rv);
thread->Dispatch(event, NS_DISPATCH_NORMAL);


== From JS ==
== From JS ==
Line 369: Line 341:
== Development ==
== Development ==


Development is occuring on the THREADS_20060213_BRANCH.  See also {{bug|326273}}.
Development is occuring on the THREADS_20060307_BRANCH.  See also {{bug|326273}}.


== Comments ==
== Comments ==
Line 397: Line 369:


I think the answer is to be careful about making callbacks across XPCOM boundaries where event queues may be pumped.  Maybe the layout code needs to unwind the stack more before allowing such callbacks to happen so that it can be sure that event processing won't be the end of the world.
I think the answer is to be careful about making callbacks across XPCOM boundaries where event queues may be pumped.  Maybe the layout code needs to unwind the stack more before allowing such callbacks to happen so that it can be sure that event processing won't be the end of the world.
dbaron: Also, with the new push/popEventQueue API defined on nsIThreadInternal, it is possible to suppress event dispatch for a particular scope.  That is needed to implement synchronous XPCOM proxy calls.  I'm assuming that any proper use of synchronous XPCOM proxy calls will be one that completes relatively quickly so as to negate the effects of locking up the browser.  We should probably be very careful about calling PushEventQueue on the main thread, where it would potentially disrupt the browser UI.  Native events would still be dispatched as always, but without application level events, the UI isn't very useful.
Darin
272

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/18416...25141"