interdependents have indicated they're blocking to check. Otherwise the unit running before the
last BlockingUnit can post to the presents invoker and those newly posted units will be skipped.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6006 542714f4-19e9-0310-aa3c-eee0fc999fb1
- PresentsInvoker decides it's empty
- It waits on other dependencies
- During the wait, something (probably from one of the other dependencies) posts to the PresentsInvoker
- We loop back around, the dependencies are empty
- We end early, with the posted bit still to be done...
So... after waiting, do a quick check for emptyness and if not satisfied, start the whole dern cycle over.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6005 542714f4-19e9-0310-aa3c-eee0fc999fb1
actually reduce latency, but wouldn't it be cool if it did?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5985 542714f4-19e9-0310-aa3c-eee0fc999fb1
injected handling by subclasses.
I had a nice version of this that allowed user controlled handling for any signal to be injected.
Unfortunately it used multibindings from guice, and I'm loathe to add a dependency to narya just for
that.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5980 542714f4-19e9-0310-aa3c-eee0fc999fb1
logs that it's listening on its configured ports, when start() is called. It
does so on a separate thread, but I don't believe the subtle ordering
possibilities there are something that's actually causing/likely to cause
problems and/or needs to be called out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5947 542714f4-19e9-0310-aa3c-eee0fc999fb1
No need to tell the server the callerOid, it already knows it.
This saves 4 bytes for every listener you pass into an invocation request.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5908 542714f4-19e9-0310-aa3c-eee0fc999fb1
checking the PresentsInvoker itself and the DObjectMgr. Expose waiting for all theses queues to
empty on PresentsInvoker such that Presents servers can do things like wait for all the queues to
empty before opening to the public.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5898 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
that would throw a NotYetConnectedException when you tried to write to it. Yes,
you'd definitely think that.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5865 542714f4-19e9-0310-aa3c-eee0fc999fb1
the case for an outgoing connection since we do our connection asynchronously)
and a connection that is no longer connected because it once was open and now
it's closed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5855 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
dependency, but we can inject RunQueue which will Guice will magically defer to
avoid the circularity.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5847 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
PresentsSession, we don't need to or want to change our auth name, we can and
should operate entirely on ClientObject.username. The ClientManager maintains
two mappings: "current username" -> ClientObject (which is what needs to change
when setUsername or updateUsername is called) and "authname" -> PresentsSession
which has always been just the authname and has never changed during the course
of a session. PresentsSession.getUsername() goes away and
PresentsSession.getAuthName() always returns the name that was used to
authenticate the session.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5838 542714f4-19e9-0310-aa3c-eee0fc999fb1
Charlie Groves