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