Potential concurrency problem in AsyncChannelAsserts

[joshua-g]

There's a potential concurrency problem with the throwables arrays in methods waitForReply and listenTo: these arrays seem to be accessed from more than one thread without synchronization.

It might be better for the Fibers in these methods to be created, started, and disposed externally; then test fibers can be reused, and exceptions can be collected by a JUnitRuleFiberExceptions instance. I also think that, in general, it's a better Fiber usage pattern if a Fiber passed into a constructor is disposed by the caller, though arguably in this case it doesn't matter.

[ryanobjc]

There is something about fiber lifecycle being managed outside the scope of an active object that bothers me. I think in part because it should be stand alone.

Then again, a lot of objects are sub objects of some other system. Failure of that fiber and object must be handled outside the scope no matter what anyways. =