272
edits
XPCOM:nsIThreadManager: Difference between revisions
Jump to navigation
Jump to search
m
→Remarks
m (→Remarks) |
|||
| Line 357: | Line 357: | ||
* 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. | * 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 <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. | * 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: <code>nsIEventQueue</code>, <code>nsIEventQueueService</code>, <code>nsIEventTarget</code>, <code>nsIThread</code>, <code>PLEvent</code>. | ||
* 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. | ||