272
edits
XPCOM:nsIThreadManager: Difference between revisions
→Remarks
m (→Interfaces) |
|||
| Line 140: | Line 140: | ||
== Remarks == | == Remarks == | ||
* Thread priority for native threads can be exposed via <code>nsISupportsPriority</code>. | |||
* Thread priority for native threads can be exposed via nsISupportsPriority | |||
* 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 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. | ||
| Line 149: | Line 146: | ||
* 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? == | |||
The main thread where UI events are processed and the socket transport thread will use the observer interface defined by <code>nsIThreadInternal</code>. The main thread will interact with the "native" event system during calls to <code>ProcessNextEvent</code> and <code>Dispatch</code>. Likewise, the socket transport thread will similarly need to poll sockets and perform I/O operations. By observing calls to <code>ProcessNextEvent</code>, observers can wait on a native event queue (or poll on a set of file descriptors) instead of waiting on the thread's internal event queue monitor. When they observe a call to <code>Dispatch</code>, they can use whatever mechanism is appropriate to unblock the thread that is waiting on the native event queue. | |||
== How do synchronous tasks work? == | == How do synchronous tasks work? == | ||