Open Bug 1036550 Opened 10 years ago Updated 2 years ago

Redesign nsITimer implementation

Categories

(Core :: XPCOM, defect)

x86_64
Windows 7
defect

Tracking

()

People

(Reporter: benjamin, Unassigned)

References

Details

The current implementation of nsITimer is pretty finicky in terms of threading. We should consider whether there are simpler and safer ways to implement timers.
My thoughts:

* Couple timers more tightly with nsThread
* Each thread should maintain a sorted (linked?) list of timers targeted at it. The nsThread::mMutex should protect access to that list.
* There should be no timer thread
* When a thread blocks waiting on an event, it should use a wait timeout to wake at the next schedule timer event.
* The only time we would need to explicitly wake a thread is if a timer is posted which will fire before the thread is scheduled to wake
It may even be possible for timer objects to be single-threaded in both impl and refcounting, if we never modify timers from another thread. Does anyone know if we actually rely on multi-thread timer calls currently?
I don't know. But I would expect a timer class as handy as chrome's message loop where we can post timer tasks from arbitrary threads. For now, I have to send a runnable to the target thread in order to schedule a timer callback.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.