From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 7D6EE7EEF6 for ; Mon, 15 Jun 2015 18:45:56 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.13,618,1427752800"; d="scan'208";a="165416380" Received: from meleze.ens.fr (HELO [129.199.99.114]) ([129.199.99.114]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 15 Jun 2015 18:45:56 +0200 Message-ID: <557F0144.8030606@inria.fr> Date: Mon, 15 Jun 2015 18:45:56 +0200 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Unit testing Core Async There is a google group for Janestreet Core: https://groups.google.com/forum/#!forum/ocaml-core You might get more luck in there and some Async specialists. On 06/15/2015 06:33 PM, Kenneth Adam Miller 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? -- Regards, Francois. "When in doubt, use more types"