gecko-dev/xpcom/threads/nsTimerImpl.h

170 строки
4.5 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
2012-05-21 15:12:37 +04:00
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef nsTimerImpl_h___
#define nsTimerImpl_h___
//#define FORCE_PR_LOG /* Allow logging in the release build */
#include "nsITimer.h"
#include "nsIEventTarget.h"
#include "nsIObserver.h"
#include "nsCOMPtr.h"
#include "prlog.h"
#include "mozilla/TimeStamp.h"
#include "mozilla/Attributes.h"
#ifdef MOZ_TASK_TRACER
#include "TracedTaskCommon.h"
#endif
#if defined(PR_LOGGING)
extern PRLogModuleInfo* GetTimerLog();
#define DEBUG_TIMERS 1
#else
#undef DEBUG_TIMERS
#endif
#define NS_TIMER_CID \
{ /* 5ff24248-1dd2-11b2-8427-fbab44f29bc8 */ \
0x5ff24248, \
0x1dd2, \
0x11b2, \
{0x84, 0x27, 0xfb, 0xab, 0x44, 0xf2, 0x9b, 0xc8} \
}
enum
{
CALLBACK_TYPE_UNKNOWN = 0,
CALLBACK_TYPE_INTERFACE = 1,
CALLBACK_TYPE_FUNC = 2,
CALLBACK_TYPE_OBSERVER = 3
};
class nsTimerImpl MOZ_FINAL : public nsITimer
{
public:
typedef mozilla::TimeStamp TimeStamp;
nsTimerImpl();
static nsresult Startup();
static void Shutdown();
friend class TimerThread;
friend struct TimerAdditionComparator;
void Fire();
// If a failure is encountered, the reference is returned to the caller
static already_AddRefed<nsTimerImpl> PostTimerEvent(
already_AddRefed<nsTimerImpl> aTimerRef);
void SetDelayInternal(uint32_t aDelay);
NS_DECL_THREADSAFE_ISUPPORTS
NS_DECL_NSITIMER
int32_t GetGeneration()
{
return mGeneration;
}
#ifdef MOZ_TASK_TRACER
void DispatchTracedTask()
{
mTracedTask = mozilla::tasktracer::CreateFakeTracedTask(*(int**)(this));
}
#endif
virtual size_t SizeOfIncludingThis(mozilla::MallocSizeOf aMallocSizeOf) const;
private:
~nsTimerImpl();
nsresult InitCommon(uint32_t aType, uint32_t aDelay);
void ReleaseCallback()
{
// if we're the last owner of the callback object, make
// sure that we don't recurse into ReleaseCallback in case
// the callback's destructor calls Cancel() or similar.
uint8_t cbType = mCallbackType;
mCallbackType = CALLBACK_TYPE_UNKNOWN;
if (cbType == CALLBACK_TYPE_INTERFACE) {
NS_RELEASE(mCallback.i);
} else if (cbType == CALLBACK_TYPE_OBSERVER) {
NS_RELEASE(mCallback.o);
}
}
bool IsRepeating() const
{
Bug 650379. Add a new XPCOM timer type that is like TYPE_REPEATING_PRECISE but does not swamp the event queue if the callback takes longer than the timer interval to run. r=cjones, sr=brendan This implements proposal 3 from bug 650379 comment 13. The main difference between TYPE_REPEATING_PRECISE and TYPE_REPEATING_PRECISE_CAN_SKIP is to not AddTimer the REPEATING_PRECISE_CAN_SKIP timer until after the callback has run; this guarantees that no more timer events will be posted until after the callback finishes executing. A secondary change is to make REPEATING_PRECISE_CAN_SKIP timers advance their firing time to mDelay from when PostTimerEvent is called, not mDelay from the old mTimeout. While this arguably makes them less precise, the alternative is that if a timer is significantly delayed for some reason (e.g. because the user puts the computer to sleep for a while) it will then fire a whole bunch of times to "catch up" to where it's supposed to be, advancing its firing time by mDelay at a time. That seems undesirable. An alternate approach would have been to readd the timer from inside PostTimerEvent, but only if we're not in the middle of firing the timer. That would allow more precise timers in the case when the callback is not taking too long, but still handle gracefully the case when the callback is slow. Unfortunately this falls down if something _else_ is hogging the main thread event loop (e.g. some other timer has a slow callback, or whatever); in that case we would post multiple events for the one precise timer while the event-loop-hogging operation is running. So I don't think we should do that.
2011-04-29 03:33:52 +04:00
PR_STATIC_ASSERT(TYPE_ONE_SHOT < TYPE_REPEATING_SLACK);
PR_STATIC_ASSERT(TYPE_REPEATING_SLACK < TYPE_REPEATING_PRECISE);
PR_STATIC_ASSERT(TYPE_REPEATING_PRECISE < TYPE_REPEATING_PRECISE_CAN_SKIP);
return mType >= TYPE_REPEATING_SLACK;
}
bool IsRepeatingPrecisely() const
{
Bug 650379. Add a new XPCOM timer type that is like TYPE_REPEATING_PRECISE but does not swamp the event queue if the callback takes longer than the timer interval to run. r=cjones, sr=brendan This implements proposal 3 from bug 650379 comment 13. The main difference between TYPE_REPEATING_PRECISE and TYPE_REPEATING_PRECISE_CAN_SKIP is to not AddTimer the REPEATING_PRECISE_CAN_SKIP timer until after the callback has run; this guarantees that no more timer events will be posted until after the callback finishes executing. A secondary change is to make REPEATING_PRECISE_CAN_SKIP timers advance their firing time to mDelay from when PostTimerEvent is called, not mDelay from the old mTimeout. While this arguably makes them less precise, the alternative is that if a timer is significantly delayed for some reason (e.g. because the user puts the computer to sleep for a while) it will then fire a whole bunch of times to "catch up" to where it's supposed to be, advancing its firing time by mDelay at a time. That seems undesirable. An alternate approach would have been to readd the timer from inside PostTimerEvent, but only if we're not in the middle of firing the timer. That would allow more precise timers in the case when the callback is not taking too long, but still handle gracefully the case when the callback is slow. Unfortunately this falls down if something _else_ is hogging the main thread event loop (e.g. some other timer has a slow callback, or whatever); in that case we would post multiple events for the one precise timer while the event-loop-hogging operation is running. So I don't think we should do that.
2011-04-29 03:33:52 +04:00
return mType >= TYPE_REPEATING_PRECISE;
}
nsCOMPtr<nsIEventTarget> mEventTarget;
void* mClosure;
union CallbackUnion
{
nsTimerCallbackFunc c;
nsITimerCallback* i;
nsIObserver* o;
} mCallback;
// Some callers expect to be able to access the callback while the
// timer is firing.
nsCOMPtr<nsITimerCallback> mTimerCallbackWhileFiring;
// These members are set by Init (called from NS_NewTimer) and never reset.
uint8_t mCallbackType;
// These members are set by the initiating thread, when the timer's type is
// changed and during the period where it fires on that thread.
uint8_t mType;
bool mFiring;
// Use a bool (int) here to isolate loads and stores of these two members
// done on various threads under the protection of TimerThread::mLock, from
// loads and stores done on the initiating/type-changing/timer-firing thread
// to the above uint8_t/bool members.
bool mArmed;
bool mCanceled;
// The generation number of this timer, re-generated each time the timer is
// initialized so one-shot timers can be canceled and re-initialized by the
// arming thread without any bad race conditions.
int32_t mGeneration;
uint32_t mDelay;
TimeStamp mTimeout;
#ifdef MOZ_TASK_TRACER
nsAutoPtr<mozilla::tasktracer::FakeTracedTask> mTracedTask;
#endif
#ifdef DEBUG_TIMERS
TimeStamp mStart, mStart2;
static double sDeltaSum;
static double sDeltaSumSquared;
static double sDeltaNum;
#endif
};
#endif /* nsTimerImpl_h___ */