From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE, SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 16FF1BB84 for ; Mon, 27 Oct 2008 16:45:22 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAFJ/BUlQW+UCe2dsb2JhbACUAAEBFiIErl+DTw X-IronPort-AV: E=Sophos;i="4.33,492,1220220000"; d="scan'208";a="19256265" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 27 Oct 2008 16:45:21 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m9RFjLEh014334 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Mon, 27 Oct 2008 16:45:21 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAFJ/BUlQW+UCe2dsb2JhbACUAAEBFiIErl+DTw X-IronPort-AV: E=Sophos;i="4.33,492,1220220000"; d="scan'208";a="19256260" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 27 Oct 2008 16:45:21 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KuUHK-0003Si-3O for caml-list@inria.fr; Mon, 27 Oct 2008 15:45:14 +0000 Received: from ivr94-8-88-162-26-239.fbx.proxad.net ([88.162.26.239]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Oct 2008 15:45:14 +0000 Received: from zheng_li by ivr94-8-88-162-26-239.fbx.proxad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Oct 2008 15:45:14 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Zheng Li Subject: Re: [ANN] camlish: a simple module for shell scripting in OCaml Date: Mon, 27 Oct 2008 16:45:48 +0100 Message-ID: <4905E22C.3010703@users.sourceforge.net> References: <490535D8.8020500@users.sourceforge.net> <4905D1C7.7090102@users.sourceforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ivr94-8-88-162-26-239.fbx.proxad.net User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) In-Reply-To: Sender: news X-Miltered: at discorde with ID 4905E211.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 mikkel:01 mikkel:01 rgensen:01 parallelism:01 lib:01 ocaml's:01 lib:01 synchronous:01 async:01 synchronous:01 async:01 combinators:01 combinator:01 parallelism:01 Hi Mikkel, I didn't see your post appearing on list, but I think maybe there are other also interested in this topic, so I reply to the list directly. Mikkel Fahnøe Jørgensen wrote: > I'm sorry for not being clear > > I did _not_ mean: would it be smart for camlish to take advantage of LWT ... > > I did mean: for users buying into asynchronous programming using the > LWT interface, it is critical to avoid blocking, or everything stops. > The usual read / write functions have been wrapped asynchronously. > > Say you are on a web server handling various backend processes. You > want to pipeline some image transformation and compression using a > shell pipeline. > > Now it would be sad to block the web server while the image is completed. > But it would be nice to use a powerful shell scripting interface to > manipulate images. > And it would be nice to take advantage of parallelism for performance, > not just to avoid blocking. Now I understand what you meant. Yes, asynchronous lib such as Lwt requires every possibly blocking operation to be asynchronous, i.e. return a value of Lwt.t. For OCaml's type system, it's not obliged, but then you are not asynchronous any more. It's like the common problem of monad, once you get one, it has to spread everywhere. However, I think it's not practical to ask every library developer to adopt the asynchronous style and bind their type definition to a specific lib. > More comments below: Me too :) >> * If you meant to use them together, I think that's fine. They >> are both user level libraries, Lwt has an asynchronous interface, >> camlish has a synchronous one, so you can just use camlish API as >> common functions application everywhere. > > So this is possible, but will apparently block the LWT thread system ... > LWT does have an option to park external operations in a system thread I didn't know about that. When I looked at it, it didn't have that, but maybe they added it later. > so that might be a way to go? Yes, I think so. It should be the asynchronous lib to deal with that, otherwise we have to ask every library author to be aware of it. In Async, we provide a few functions to help wrapping synchronous functions into asynchronous ones. So other libraries don't have to change, but still this is not transparent. >> * If you meant to implement the inside asynchronous mechanics of >> camlish on top of Lwt, I did thought of that. Actually, I have >> another library called Async does similar thing as Lwt. It's >> possible, but not necessary. Besides, the CPS-based approach >> always brings some syntactic burdens, which I prefer to avoid. >> So finally, the inside implementation of camlish is asynchronous, >> while we only expose the synchronous interface to the outside world. > > Async could be an alternative to LWT, I have not looked at it, but the > it is the same issue. You would not want to block the threads while > calling shell commands. It has been used internally, but not released yet. I haven't got the time to clean up the code. >> * Maybe you were though about parallel execution? Pipeline is >> parallel already, plus there are two parallel combinators have >> been planed (opposite to "&&&", the sequential combinator). I >> haven't seen this kind of stuff in other shells, but I think that's >> reasonable. > > Yes that too. Fire off all the shell commands and have an LWT thread > monitor them and feed the result in the LWT thread chain. Sure. What you want in you post is concurrency not parallelism. -- Zheng