when posted to a shutdown queue. There's a method we can override for that now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6013 542714f4-19e9-0310-aa3c-eee0fc999fb1
preserve Interval's behavior of not executing an interval that was canceled
after it was posted to its runqueue but before it was executed we have to do
some nested craziness.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5882 542714f4-19e9-0310-aa3c-eee0fc999fb1
automatically canceled when the omgr is shutdown (they actually cancel
themselves if they fire after the omgr has been shutdown, which stock intervals
also do, but these guys do so quietly because we know they mean to work that
way).
Made use of that new method and the fluent schedule methods in various places.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5880 542714f4-19e9-0310-aa3c-eee0fc999fb1
operations, but previously if someone called destroy on an uninitialized DObject or called
PresentsDObjectManager.destroyObject with its oid, it'd be destroyed. Subscribing to objects
depends on that object existing, so if it's destroyed, the server will continue to function normally
except that subscription requests will be silently dropped.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5851 542714f4-19e9-0310-aa3c-eee0fc999fb1
specialized ReportManager, let's just not activate them by default.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5846 542714f4-19e9-0310-aa3c-eee0fc999fb1
point Pulse can probably totally replace the ReportManager at which time a
bunch of cruft can go away.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5757 542714f4-19e9-0310-aa3c-eee0fc999fb1
PresentsDObjectMgr to achieve a coordinated shutdown.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5531 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Throw an exception if any events, runnables or messages are posted after shutdown. These were previosuly being silently ignored. We really should know about them.
* Don't exit the connection manager thread until the object manager thread exits. This fixes a race condition where the wakeup time of the conmgr thread would determine if it shutdown before or after the object manager, meaning it would sometimes ignore messages around shutdown time.
* Add a shutdown constraint to make the client manager shutdown before the invoker/event/conmgr threads. This gives a single point in the shutdown sequence that applications can use as a constraint (TODO: shutdown groups?)
* Emit a log message for each shutdown method call. This could be very useful in production.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5491 542714f4-19e9-0310-aa3c-eee0fc999fb1
thing before committing instead of just going "oh yeah, I've been having this stuff
sitting around uncommitted for a while waiting on it to be blessed" and missing
out on things that'd changed in the meantime.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5400 542714f4-19e9-0310-aa3c-eee0fc999fb1
importing receivers from their senders to satisfy their links.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5333 542714f4-19e9-0310-aa3c-eee0fc999fb1
directly to stderr. Logging an exception with the associated warning does the
right thing and logs the stack trace via the logging system.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5318 542714f4-19e9-0310-aa3c-eee0fc999fb1
server initialization phase. Only after the event thread is established is it
unsafe to be wild and wooly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5315 542714f4-19e9-0310-aa3c-eee0fc999fb1
CheckStyle. The checks are slightly looser than I'd like but way better than
nothing and we get a bunch of other useful warnings like shadowed names and
other handy bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5253 542714f4-19e9-0310-aa3c-eee0fc999fb1
dependency resolution and management. Things are currently in a state of
transition, but the important patterns have been established and I'll aim to
sweep through all of Narya, Nenya and Vilya in the near future and do
everything properly.
Going through the other million-odd lines of code we have scattered across our
various projects that use these libraries is not something I plan to do, so
we'll be maintaining backward compatibility with the old static member method,
though I hope to strive toward eradication of that usage entirely in MSOY while
we still have a fighting chance.
Given that some of our projects will continue to use the static member method
in perpetuity, I'm not going to @Deprecate those fields because that would fill
their logs with so much spam that they'd have to turn off deprecation warnings
which would make life worse for them. So instead we'll settle for the big scary
comment warning people away from the old bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5153 542714f4-19e9-0310-aa3c-eee0fc999fb1
Also, added logging to the PresentsDObjectMgr to check for this type of thing and dump stack if anyone is trying to register objects anywhere but the DObj thread (assuming we're sufficiently far started up that there is one).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4832 542714f4-19e9-0310-aa3c-eee0fc999fb1
the dobjmgr thread to relieve the caller of the burden of knowing what thread
they are on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4826 542714f4-19e9-0310-aa3c-eee0fc999fb1
(pre-applied and) posted before we received our object but processed (and hence
dispatched to us) after we received our object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4715 542714f4-19e9-0310-aa3c-eee0fc999fb1
something funny is happening with spurious objects dispatched across servers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4657 542714f4-19e9-0310-aa3c-eee0fc999fb1
Dave Hoover