flattens messages into a buffer and then passes that bucket to a
SocketChannel.write() method which is part of the NIO business. If said
buffer is a "direct" buffer, the write() method will in theory do
high-performance shit like DMA the data right to the network card. If it's
not a direct buffer, Sun apparently makes a temporary direct buffer,
copies the data into it and passes that on to the underlying socket send()
call. We weren't using direct buffers which means that we were copying
everything one more time than needed (not a huge deal) and that we were
allocating a direct buffer for every message (a much bigger deal). This
should take a serious load off of the I/O thread and fortunately we can
test it on Ice to make sure it doesn't do anything super crazy.
All this said, this whole business is going to change when I rearchitect
Presents to avoid the potential race conditions it suffers from now and we
won't be able to use a single direct buffer to write all of our outgoing
messages, but I believe we will be able to use a pool of direct buffers
with one used by every message in the queue waiting to be written
(hopefully that won't be too many at any given time) which we can keep
around to avoid the expense of allocating and freeing direct buffers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3336 542714f4-19e9-0310-aa3c-eee0fc999fb1
sufficiently incompatible with GNU make that I'd rather just have two
whole separate goddamned directories with their own Makefile than try
to get everyone to agree on how to do things.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3328 542714f4-19e9-0310-aa3c-eee0fc999fb1
the throes of a previous connection. Also don't spuriously recreate our
ticker because it's very possible for logon() to be called and not
logoff(), logon() might fail, for example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3321 542714f4-19e9-0310-aa3c-eee0fc999fb1
has been changed, except the names to protect the innocent.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3316 542714f4-19e9-0310-aa3c-eee0fc999fb1
changed the output format to be the same as the one for DObjectManager
profiling output.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3309 542714f4-19e9-0310-aa3c-eee0fc999fb1
actually dispatching the event to subscribers. We can't trust anyone.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3308 542714f4-19e9-0310-aa3c-eee0fc999fb1
rectangle of the area that would have been copied, as we know that the
_entire_ visible area is now dirty due to the failed copy. Replace the
list of dirty rectangles with one rectangle encompassing everything, it will
cut down on the iterations in the paint() method and should improve
performance on the JVM that exhibits the copyArea bug.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3307 542714f4-19e9-0310-aa3c-eee0fc999fb1
The SoundManager used to keep the AudioSystem's Line open for up to 30
seconds after a sound was played, maybe because I thought that opening
the line was expensive, or because it makes an audible 'tick' in linux
if no other sounds are playing. Well, it turns out that the sound looping
bug is the result of some internal befuckery of Sun's caused by keeping
the line open. Restructed the sound manager so that lines are opened
every time a sound is to be played and then closed immediately after.
This also allowed me to simplify a thing or two, and sounds should actually
be more responsive, in a tiny way, since previously the dobj thread asked
to play a sound, the sound manager thread would load the clip data and
finally a data spooling thread would play the actual sound. Now there is
no sound manager thread- so the dobj thread adds a sound to the queue and
one of the playing threads wakes up, reads the data and plays the sound.
Factored out all the music stuff into a new MusicManager. There was almost
nothing shared between the two, and it was just annoying to have one
monolithic manager that had all the logic and variables for both of these
distinct functions. The music manager also no longer has a processing
queue, everything takes place on the dobj thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3303 542714f4-19e9-0310-aa3c-eee0fc999fb1
objects (DSet, arrays) in a DEvent (which should not change as a result of
other events being applied) and those in the object itself (which do
change and evolve as events are applied to the object).
This is important both because the DEvent is passed on to another thread
for delivery to remote clients, thus changes to the values in the event
could take place before they were serialized and sent over the network,
and because compound events are applied to an object before they are sent
to the other thread for delivery and thus, for example, setting a DSet and
then adding a few entries to it in a compound event would result in the
DEvent copy of the DSet becoming corrupted.
Two problems remain (note, neither of these are new, the one issue
introduced when I rewrote the DObject stuff is fixed by these checkins):
1. Object subscription requests are supposed to deliver a snapshot of the
object at the point in the event stream at which the subscription
request was processed, but presently we pass only a reference to the
object off to the networking thread which means that before the object
is serialized and sent to clients, subsequent events could be applied
to it and then those events would be sent to the client as well
resulting in funny business (probably nothing more than duplicate DSet
entry warnings, but imagination and Chapter 17 tell us that worse
things could happen).
2. The use of Streamable instances could result in badness. If a field in
a Streamable is modified and the whole Streamable set() back into the
object to broadcast the update, then further changes were made to the
Streamable before the attribute change event was serialized and sent
over the network, the second modifications would be reflected in the
event triggered by the first modifications.
The first problem may be solvable (albeit inefficiently) by serializing
the DObject on the event dispatcher thread and sending that serialized
copy off to the network thread for delivery to the client. It would be
much less efficient as we would be unable to make use of the client's
already "primed" ObjectOutputStream which may have already mapped many of
the classes in the object to two byte codes, but object subscription is
fairly uncommon compared to delivery of events, so inefficiency might not
be a big problem in this case.
The second problem might be solved by requiring that all Streamable
implementations implement clone() and then cloning any Streamable
attribute just as we do an array or DSet during an attribute, array
element or DSet entry change. This would be a more significant performance
hit as well as require a review of all of our Streamable classes (to
determine if they need a custom clone() implementation), and it has up to
now not actually manifested as a problem.
In any case I'm not going to tackle either of these remedies at the moment
because I'm on vacation, dammit.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3294 542714f4-19e9-0310-aa3c-eee0fc999fb1
because it plays games in a special place rather than actually moving the
player into the game room which naturally registers the place object as a
chat source. Fortunately, we can implement the necessary hackery to
support Yohoho in a reasonably generic manner.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3291 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne