canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,334
edits
XPCOM:nsIThreadManager: Difference between revisions
Jump to navigation
Jump to search
→Comments
m (→Remarks) |
|||
| Line 383: | Line 383: | ||
* If you are sync dispatching, then it is necessary to pump events on the calling thread or else you could end up in a dead-lock situation. For example, if thread A sync dispatches an event to thread B, which cannot complete its job without dispatching an event back to thread A, then the system will dead-lock unless thread A continues to dispatch pending events. | * If you are sync dispatching, then it is necessary to pump events on the calling thread or else you could end up in a dead-lock situation. For example, if thread A sync dispatches an event to thread B, which cannot complete its job without dispatching an event back to thread A, then the system will dead-lock unless thread A continues to dispatch pending events. | ||
* <code>ProcessNextEvent</code> may be called by anybody that wishes to implement the concept of a "modal event loop." For example, XMLHttpRequest (in sync configuration) would sit in a loop calling <code>ProcessNextEvent</code> while waiting for the underlying HTTP transaction to complete. The key difference between <code>ProcessNextEvent</code> and <code>nsIEventQueue::ProcessPendingEvents</code> is that <code>ProcessNextEvent</code>, when called on the UI thread, will process UI events as well. And, it will also wait (block the thread of execution) if there are no UI events or pending <code>nsIRunnable</code> events. | * <code>ProcessNextEvent</code> may be called by anybody that wishes to implement the concept of a "modal event loop." For example, XMLHttpRequest (in sync configuration) would sit in a loop calling <code>ProcessNextEvent</code> while waiting for the underlying HTTP transaction to complete. The key difference between <code>ProcessNextEvent</code> and <code>nsIEventQueue::ProcessPendingEvents</code> is that <code>ProcessNextEvent</code>, when called on the UI thread, will process UI events as well. And, it will also wait (block the thread of execution) if there are no UI events or pending <code>nsIRunnable</code> events. | ||
=== dbaron: === | |||
So mrbkap was telling me at lunch about what's essentially the third bullet point of your comment to biesi above -- that you're making the concept of "modal event loop" even more powerful. This actually scares me a good bit, because these modal event loops happen within another event -- an event that may have state on the stack (e.g., |this| parameters) that could be destroyed by the processing of further events, or may have posted events that rely on the event completing. I really don't like the mix of programming models here that makes it very hard to write robust code, and I wish we could avoid this whole concept altogether rather than making it even more powerful, and thus more dangerous. We already have crashes where frame trees get destroyed while processing an event that are related to the Windows API's way of doing the same thing, though (for, e.g., a DestroyWindow call or whatever it's called). | |||