From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 E7DC27EE4B for ; Mon, 30 Sep 2013 10:16:08 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.90,1006,1371074400"; d="scan'208";a="34857489" Received: from dhcp-rocq-121.inria.fr (HELO [128.93.62.121]) ([128.93.62.121]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 30 Sep 2013 10:16:07 +0200 Message-ID: <52493343.7020509@inria.fr> Date: Mon, 30 Sep 2013 10:16:03 +0200 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Tom Ridge CC: caml-list , Benedikt Grundmann References: <52455D91.6000304@inria.fr> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Validation-by: romain.bardou@inria.fr Subject: Re: [Caml-list] Thread behaviour It happens I implemented a library to handle messaging between possibly-distributed OCaml processes myself. Well, for now one can only send one message and receive one message: the goal is to be able to run a function 'a -> 'b in another process, given marshaling functions for 'a and 'b and exceptions. I do plan to add the possibility of sending more "intermediate" messages (I need it). It works on Linux and Windows. I did not do any official release yet, but you can have a look here: https://github.com/cryptosense/procord You can clone the directory and "make doc" to view the Ocamldoc documentation in HTML. (I would have put it on my web page but I can't access it right now.) In the documentation directory there is a motivation.txt file which explains the need for the library and compares it to other solutions. I need this library for a commercial product, so I plan to maintain it in the long run. If you plan to build your own library, consider contributing to Procord instead :) If you don't want to I would be happy to hear what you want to do differently. I will present Procord at the next OUPS meeting, and I plan to do an official release before that. Before, I need to check whether the MIT license must be copied to every source file or whether a LICENSE file in the root directory is enough. Cheers, -- Romain Bardou Le 28/09/2013 21:09, Tom Ridge a écrit : > Would it be fair to say that OCaml does not currently support > pre-emptively scheduled threads? > > I have read the lecture from Xavier archived here: > > http://alan.petitepomme.net/cwn/2002.11.26.html#8 > > I would like to implement a library to handle messaging between > possibly-distributed OCaml processes. Alas, my design naively requires > pre-emptively scheduled threads (although it may be possible to change > the design e.g. to work with Lwt) - each message queue is accompanied > by a thread which reinitializes connections when connections go down > etc., hiding this complexity from the user. > > Quoting Xavier: > > "Scheduling I/O and computation concurrently, and managing process > stacks, is the job of the operating system." > > But what if you want to implement a messaging library in OCaml? It > seems unlikely that all operating systems would fix on a standard > implementation of distributed message passing (or, even more funky, > distributed persistent message queues). > > > On 27 September 2013 11:51, Benedikt Grundmann > wrote: >> The ticker thread will cause yields which will be honored on the next >> allocation of the thread that currently has the caml lock. That said we >> have seen that sometimes the lock is reacquired by the same thread again. >> So there are some fairness issues. >> >> >> On Fri, Sep 27, 2013 at 11:27 AM, Romain Bardou >> wrote: >>> >>> Le 27/09/2013 12:10, Tom Ridge a écrit : >>>> Dear caml-list, >>>> >>>> I have a little program which creates a thread, and then sits in a loop: >>>> >>>> -- >>>> >>>> let f () = >>>> let _ = ignore (print_endline "3") in >>>> let _ = ignore (print_endline "hello") in >>>> let _ = ignore (print_endline "4") in >>>> () >>>> >>>> let main () = >>>> let _ = ignore (print_endline "1") in >>>> let t = Thread.create f () in >>>> (* let _ = Thread.join t in *) >>>> let _ = ignore (print_endline "2") in >>>> while true do >>>> flush stdout; >>>> done >>>> >>>> let _ = main () >>>> >>>> -- >>>> >>>> I compile the program with the following Makefile clause: >>>> >>>> test.byte: test.ml FORCE >>>> ocamlc -o $@ -thread unix.cma threads.cma $< >>>> >>>> When I run the program I get the output: >>>> >>>> 1 >>>> 2 >>>> >>>> and the program then sits in the loop. I was expecting the output from >>>> f to show up as well. If you wait a while, it does. But you have to >>>> wait quite a while. >>>> >>>> What am I doing wrong here? I notice that if I put Thread.yield in the >>>> while loop then f's output gets printed pretty quickly. But why should >>>> the while loop affect scheduling of f's thread? >>>> >>>> Thanks >>>> >>> >>> OCaml's thread, unfortunately, are kind of cooperative: you need to >>> yield explicitly. Note that you will obtain an even different (worse) >>> result with a native program. I observed this myself without looking at >>> the thread code itself so maybe there is actually a way to >>> "automatically yield" but as far as I know there is no way to obtain the >>> behavior you want without using either yields or processes instead of >>> threads. This is the reason for the Procord library I am developing >>> (first version to be released before the next OUPS meeting). >>> >>> Also, you don't need to ignore the result of print_endline, as >>> print_endline returns unit. And using let _ = ... in is the same as >>> using ignore, so using both is not needed. >>> >>> Cheers, >>> >>> -- >>> Romain Bardou >>> >>> -- >>> Caml-list mailing list. Subscription management and archives: >>> https://sympa.inria.fr/sympa/arc/caml-list >>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>> Bug reports: http://caml.inria.fr/bin/caml-bugs >> >>