Internally at Jane Street -- and this may show up in some of the publicly released code, but off the top of my head, I don't know what file to point you at -- we run some of our async unit tests using [Thread_safe.block_on_async_exn]. That will spin up the scheduler if necessary, run the function you give it, block until the deferred is determined, then return. It does not shut down the async scheduler; we generally don't do that until the program is done, so we would leave the scheduler up from one test to another. I don't know the entire rationale behind this design, there may be a way to shut down the scheduler in between tests, but in general it does not appear to be necessary.

As for partial reads, if you're concerned with receiving whole messages, I think [Reader.read_one_chunk_at_a_time] can do what you need -- if you get too little, just return [`Consumed (n_already_consumed, `Need n_total_bytes_to_proceed)].

I hope this helps!

On Mon, Jun 15, 2015 at 12:33 PM, Kenneth Adam Miller <kennethadammiller@gmail.com> wrote:

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?

Carl Eastlund