Initial commit: add a README.

Change-Id: Ib54e7512da93ebece76960831007ea8372634e0c
Initial commit: import the code.

Change-Id: I3c8a344febe222b7b9b0d0c2122f058b204571fa
Add a couple of convenient methods to group Deferreds together.

Oftentimes we just wanna group 2 or 3 Deferreds together, but this
doesn't compile without ugly warnings or @SuppressWarnings("unchecked"):
  Deferred<T> foo = ...;
  Deferred<T> bar = ...;
  return Deferred.group(Arrays.asList(foo, bar));

Also remove an unnecessary method call from DeferredGroup.

Change-Id: I9741a6796a2455be0b6a8ad4a05138eb209fa72a
Up MAX_CALLBACK_CHAIN_LENGTH from 64 to 127.

This need came up in the async HBase client where long callback chains
are created when lots of individual edits are quickly grouped together
before being sent to HBase.

Change-Id: Id4429ece558e5ea319445b474020bcc9eebb3524
Javadoc fixes.

Fix a couple of tyops.  Add a "tl;dr" version to give a brief overview
of what Deferred is.  Document the performance hit involved by calling
toString() on a Deferred in the fast-path of an application.

No code change.

Change-Id: I2070e198444e54b7ca0bbea09deb152ec0c63816
Switch from LGPLv3+ to BSD license.

For the records, I wanted to use the LGPL, I think it's a fair license.
Unfortunately, the ASF doesn't allow inclusion of LGPL code in their
projects, and many seemed concerned about the "virality" of the LGPL.
I don't approve this change, and I tried to resist it, but due to
popular demand, this software package is switching to the BSD license.

Change-Id: I7bc5d749ab22367dbcaa82cb3cd54ee35a6124d8
Fix join() and joinUninterruptibly() with multiple threads waiting.

The implementation of join() and joinUninterruptibly() was unsafe when
multiple threads were trying to join a common Deferred.  All threads
were waiting on the same condition, but in fact each thread needs to
have its own condition, since they need to be awaken at a different
point in the callback chain.

Example:
          Thread A                    Thread B

  Deferred<Foo> d = ...;
  d.join();                   Callback<Bar, Foo> cb = ...;
                              Deferred<Bar> = d.addCallback(cb);
			      d.join();

The callback chain looks like this:
    ...  -->  wake up callback  -->  cb  -->  wake up callback

When running, the first "wake up callback" will wake up both thread A
and thread B.  But thread B wanted to be awaken after `cb' has run, and
it will incorrectly observe a result of type Foo when it expected a
result of type Bar.

Change-Id: I38766da651ee24e71f5824aaab0ca65447effa17
Fix some bogus code in an example in the javadoc.

No actual code change.

Change-Id: I8f9f4167cd17210153946f4d29c8cfe86fa209dd
Avoid logging a confusing DEBUG message.

Sometimes it was possible to log at the DEBUG level that a Deferred was
getting paused, but the log message was showing it in state DONE, which
was confusing.

Change-Id: I644e8e6dd68f4b140cb07e19a2263431a459a24f
Stop using anonymous classes.

They make stack traces harder to understand.  With all the classes named
`Deferred$1', `Deferred$2' and whatnot, it's hard to keep track of which
one is which.

Change the code implementing join() slightly to avoid creating an
unnecessary array.

The new code is semantically equivalent to the old one.  As a bonus, the
uncompressed size of the byte code generated is 5% smaller on my laptop.

Change-Id: I4a9a743f6ab8213533544038bda5aaff91bc5268
Put additional information in the message of an AssertionError.

Change-Id: Ia0225b55e4d3e8999c4b1071f30c8d261b6d5346
Throw an AssertionError when trying to chain() a Deferred to itself.

Change-Id: I3cf28ae3ba36f7fcf217ffc19fd7219bc92cf4ef
Don't cast an int to a short without checking the result.

A large DeferredGroup could cause the conversion to turn the value into
a negative value.  Just use an integer.  If people want big groups, they
should be allowed to have them.

Change-Id: Ie5a9c1cf0dd22677cd437ad1c74d63e9143483dd
Fix a race condition when adding a callback.

The following "unlucky execution" could happen:
 Deferred in state RUNNING.
 Thread A (in runCallbacks)                 | Thread B (in addCallbacks)
   complete execution of the last callback  |   CAS state DONE -> RUNNING fails
   acquire this' monitor                    |
   observe that the callback chain is empty |
   set state to DONE                        |
   null out callback chains                 |
   release this' monitor                    |
                                            |   acquire this' monitor
					    |   queue the new callbacks
					    |   release this' monitor

Now Thread B left the Deferred in state DONE with a callback in the
chain that will never be called unless another callback is added to it.

The fix consists in swapping the CAS and the acquisition of this'
monitor in addCallbacks.  In the unlucky timing above, this could
have 2 possible outcomes:
  1. Thread A acquires this' monitor first and then thread B's CAS
     will succeed, so B will keep executing the callback chain.
  2. Thread B acquires this' monitor first and queues the new
     callbacks, then thread A will execute them.
When swapping the CAS and the acquisition of this' monitor, the CAS
becomes unnecessary and can be replaced with a regular volatile-read
followed by a regular volatile-write.  The purpose of the CAS was
originally to avoid acquiring this' monitor when it wasn't necessary
but this "optimization" wasn't even effective since the most common
code path is to add a callback to a Deferred in state PENDING, and
this code path always needed a failed CAS + monitor acquisition.

Change-Id: I365cec225e9d15aa09280ce066bf11ce56c1d358
Optimization: don't wait on a Deferred already in State.DONE.

When a Callback returned a Deferred already in State.DONE, the current
Deferred was paused and immediately resumed, which involved the creation
of an unnecessary Continue callback and other objects.  We now bypass
this entire code path, which helps in the cases where a Callback returns
a Deferred built with Deferred.fromResult or Deferred.fromError, or if a
real Deferred completes so quickly that we directly see it in State.DONE.

Change-Id: I710266e05b5f37d676018f706c923ecafa276ffc
Start version 1.1.0.

Change-Id: I6095fc86de443d5cc6b14e99ae03a0a29a051dee
Use a single array instead of 2 LinkedList for callbacks.

In retrospect, using LinkedList was a bad idea because of the insane
amount of memory overhead it has, especially in Java.  An array can
provide the same O(1) tail insertion (amortized), O(1) head removal,
while using far less RAM.

Heap dumps in OpenTSDB frequently show a lot of memory used just for
the LinkedList head and for each LinkedList$Entry.

On x86-64, with Sun's JVM 1.6.x, this yields the following savings:
  - First callback added costs an extra 32 bytes of RAM, instead of
    144 bytes with the LinkedList implementation.
  - Second callback added doesn't cost anything extra, whereas the
    LinkedList implementation adds 48 bytes of overhead per callback.
For a typical Deferred with 2 callbacks, this translates into 160 bytes
of RAM saved per instance.

This change also improves CPU cache efficiency since now all the
references to the callbacks are in the same cacheline (or contiguous
cachelines).  The end result is that a benchmark that creates 100k
Deferred, with an equal number of Deferred with 1, 2, 3, 4 and 5
callbacks, and calls them all back runs 14-15% faster on a dual Intel
E5520, 12-16% faster on dual Intel L5630.

Change-Id: I1c5e487947fe6e478940f16172bf90a1e4021298
Add support for timed synchronous joins.

New API: The `join()' and `joinUninterruptibly()' methods now have an
overloaded version that accepts a timeout in milliseconds and throws
the new TimeoutException when a timed join times out.

Change-Id: If8c01ef0bdfa0c5cd6d558a0da35ea1ff43283d3
Release v1.1.0.

Change-Id: Id3142f69074ceaebc7f190e861dd7e2dad55b21f
Mavenize with no impact to dir hierarchy

SU Async will be available from Maven Central so projects depending on
it and building with Maven, Ant+Ivy2 or SBT can easily get it.

Likewise Asynchronous HBase client is being mavenized.

This is the initial public release of POM and seeking community
feedback.

Change-Id: I50faee3bd08a79ba886f307d1e1374eac7a76dd3