XPCOM:nsIThreadManager: Difference between revisions

Jump to navigation Jump to search
Line 142: Line 142:
* Thread priority for native threads can be exposed via <code>nsISupportsPriority</code>.
* Thread priority for native threads can be exposed via <code>nsISupportsPriority</code>.
* Thread names must be unique.
* Thread names must be unique.
* The Necko I/O thread pool would be modified to implement nsIDispatchTarget instead of nsIEventTarget.  We may even wish to define a nsIThreadPool interface and have it implement that as well.
* The Necko I/O thread pool will be replaced by a generic thread pool implementation provided by XPCOM.  The thread pool will implement <code>nsIEventTarget</code>, allowing events to be dispatched to any thread in the thread pool.  We may even wish to define a <code>nsIThreadPool</code> interface and have it implement that as well.  That interface would define methods to adjust the limits on the number of threads in the thread pool and so on.
* We will need an alternative for nsIEventQueue::revokeEvents.  There are several possibilities: (1) make consumers hold references to their nsIRunnable's so they can "disconnect" them manually, or (2) expose an enumeration/visitor API that allows consumers to walk the list of pending tasks and remove arbitrary tasks.  I'm not sure what is best yet.
* We will need an alternative for <code>nsIEventQueue::RevokeEvents</code>.  There are several possibilities: (1) make consumers hold references to their nsIRunnable's so they can "disconnect" them manually, or (2) expose an enumeration/visitor API that allows consumers to walk the list of pending tasks and remove arbitrary tasks.  I'm not sure what is best yet.  The first option or something similar based on weak references is probably best as it avoids the costly O(n) <code>RevokeEvents</code> call.
* The following interfaces/classes would go away or be modified heavily: nsIEventQueue, nsIEventQueueService, nsIEventTarget, nsIThread, PLEvent.
* The following interfaces/classes would go away or be modified heavily: nsIEventQueue, nsIEventQueueService, nsIEventTarget, nsIThread, PLEvent.
* Issue: Perhaps we should support calling <code>nsIThread::shutdown</code> from the thread itself.  That would probably have to be implemented by posting an event to the main thread, and having that thread call shutdown.  However, <code>shutdown</code> also has the property that it does not return until the thread is gone.  That obvious can't happen if <code>shutdown</code> is called on the thread itself.
* Issue: Perhaps we should support calling <code>nsIThread::Shutdown</code> from the thread itself.  That would probably have to be implemented by posting an event to the main thread, and having that thread call shutdown.  However, <code>Shutdown</code> also has the property that it does not return until the thread is gone.  That obvious can't happen if <code>Shutdown</code> is called on the thread itself.


== What happens to "native" event queues? ==
== What happens to "native" event queues? ==
272

edits

Navigation menu