I've noticed that Core Async requites that a Scheduler.go () call be placed-but that never returns. I have a Tcp.server that I'm creating, and I like to use oUnit for my tests. Monads and all are beautiful, and Core is a wonderful library, but I'm adamant that I have at least some minimal functionality testing complete that demonstrates proper behavior as well as intended usage.

What I'm wondering is the following: would there be a way to have the scheduler.go call be placed in order to fire things off, but in another thread have all the test code be dependent on the server's responses and all of that, so that once completed, it can call Shutdown.shutdown?

I tried this out, and it introduced some issues. 

First, I think that my shutdown call got executed before the unit test was able to complete. This is because using Async's Deferred introduces some complication if you want behavior to proceed sequentially as in without building deeply nested callback chains. What I'm used to is asynchronous send, and blocking receive that operates on a common execution chain. I don't see any kind of Deferred.await that blocks until the instance resolves (yes, there's upon, but that's just nesting again because it returns another deferred.

Second, I think shutdown shuts *everything* down. What I need is just to signal the completion of the job that was supposed to run, so that the Scheduler.go returns in order to allow my unit tests to run to completion.

Third, I'm not certain about the semantics of Pipe/Reader/Writer. It's not behaviorally like what I'm familiar with. For instance, callbacks may return prematurely and only have part of a message. In ZMQ, what you send is what you get. So that makes me concerned in regards to the Tcp.Server, because right now what I need is for the Pipe to just allow blocking receive so that I can make the threads coordinated, but I need the Tcp Server to allow me to receive whole protobuf messages. 

Can anyone please help me?