504005 - Consider using a thread-safe lockless queue to implement nsEventQueue

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, enhancement)

Description

[Ben Newman (:bnewman) (:benjamn)]

Vague summary reflects the undetermined scope of the reimplementation.  Some possibilities that come to mind:

  Should nsEventQueue live alongside a thread-safe lockless queue that supports a common interface (with a gradual transition towards the latter)?
  Should nsEventQueue take a constructor parameter supplying a queue object to use (one option being a thread-safe lockless queue object)?
  Should nsEventQueue be template-parameterized by the type of queue to construct (or inherit from) and use?
  Should nsEventQueue be scrapped altogether in favor of a more efficient queue with a different interface?

As a first step, it can't hurt to tighten up the nsEventQueue interface.  First to go, if my vote counts, is the public PRMonitor* Monitor() method that exposes the nsEventQueue's monitor to "power users."  The only client that I see is nsThreadPool.  I'll file a separate bug for that, blocking this one.