XPCOM:nsIThreadManager: Difference between revisions

XPCOM:nsIThreadManager (view source)

627 bytes added , 8 March 2006

m

272

edits

Revision as of 01:30, 8 March 2006 (view source) Darin (talk \| contribs) m (→‎darin:) ← Older edit		Revision as of 01:44, 8 March 2006 (view source) Darin (talk \| contribs) m (→‎darin:) Newer edit →
Line 397:		Line 397:

	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.