From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 7FF407EE4B for ; Sun, 29 Sep 2013 14:37:45 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@tot-dmz-mxout1.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@tot-dmz-mxout1.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMBANwdSFImacjlnGdsb2JhbABZgz9SriCSVoEZHg4BAQEBAQYWCTyCJQEBBUABASwLAQ8LCw0NISISAQUBChIGEwgKh2IDDwMJnQaLDIRQAQWENAMKiWQGjGYZgh8zB4QimAKBL45gGCmEaQ X-IPAS-Result: AlMBANwdSFImacjlnGdsb2JhbABZgz9SriCSVoEZHg4BAQEBAQYWCTyCJQEBBUABASwLAQ8LCw0NISISAQUBChIGEwgKh2IDDwMJnQaLDIRQAQWENAMKiWQGjGYZgh8zB4QimAKBL45gGCmEaQ X-IronPort-AV: E=Sophos;i="4.90,1004,1371074400"; d="scan'208";a="28456774" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2013 14:37:44 +0200 Received: from tot-oib-smtp1.delacy.com ([172.27.22.15] helo=tot-smtp) by tot-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1VQGFp-0003YX-68 for caml-list@inria.fr; Sun, 29 Sep 2013 08:37:41 -0400 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VQGFp-0007Uh-5K for caml-list@inria.fr; Sun, 29 Sep 2013 08:37:41 -0400 Received: from mail-ee0-f45.google.com ([74.125.83.45]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1VQGFp-000658-0M for caml-list@inria.fr; Sun, 29 Sep 2013 08:37:41 -0400 Received: by mail-ee0-f45.google.com with SMTP id c50so2113017eek.18 for ; Sun, 29 Sep 2013 05:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NQcL+nPVAHpK+p1MqH+0HK8L3hjG07l2O39NpE957vg=; b=ZnPrtPUtB6Pm9yHEKY5w2Rwma4aeOS+B8gA7ThRYbMXpI3Zax+hyhQzMZ6yw+yh0hU /luPzyUojKeOztCxGVlr9hGVE6lIHwlz8Vycc6Pk5Nghx08n6S6tYkaXup2z1VwesJ1I 06d+Yx73C5o1PHzvfebq8pBBNKSruPcsvJZus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NQcL+nPVAHpK+p1MqH+0HK8L3hjG07l2O39NpE957vg=; b=Wjgs4mQ8sBuS+zB4VV4qELyPCSKeNA1BcCQtt0NMGHAw2ZWusUHCAiQ3jm6CMF8dH7 rTGWZ0vWqZZBx8nfO+StocAmdW7Ie4Dut8UiwkQEafknLLWvOvUSDkQZ2Mm8zaF+Kl5q REw3Mh5IxdEjwZQpYyE7kq592j8DDw0EGQolpciRjlOOFIb+Etyoa+qpH8SVflzRdEru dppFPAFqn3jvZhsdJwEFzzlGZ/w5R71sKs5qWre6d6z2h9SWLCsckBWie7v5NtlzGOmr 0Pdz7Db/meZKlapbQZPfMx9REkFwFO/q2k6CN1TO4BDBKMftzk4Ywzvo3vLwuswy4VMN cANQ== X-Gm-Message-State: ALoCoQlEgH7Cua2aHbBPEWgD+esI/h3exV18RIqcGJm8f68OAUB7gKRZrDh9PK4bKAqP1IC4uNTWdMtZS9P4l6CAcSJeQB+2GNCV0hbTBviK4ZW/vcRyvEDhpDNlKZLdUdaipf7pcjTzibXWQMb0utvhRO6PFrMaVg== X-Received: by 10.14.88.65 with SMTP id z41mr27887290eee.38.1380458260280; Sun, 29 Sep 2013 05:37:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.88.65 with SMTP id z41mr27887277eee.38.1380458260164; Sun, 29 Sep 2013 05:37:40 -0700 (PDT) Received: by 10.223.180.138 with HTTP; Sun, 29 Sep 2013 05:37:39 -0700 (PDT) In-Reply-To: References: <52455D91.6000304@inria.fr> Date: Sun, 29 Sep 2013 08:37:39 -0400 Message-ID: From: Yaron Minsky To: Tom Ridge Cc: caml-list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Thread behaviour I think you've come away with the wrong conclusion. Here's my summary of the state of play. OCaml has a single runtime lock, but _does_ support pre-emptive OS threads. You can use them for concurrency but not parallelism. Code that runs in a tight loop in one thread, though, can starve another thread, particularly if it doesn't allocate, because OCaml only gives up the runtime lock when it allocates. You should probably avoid direct use of threads for concurrent programming. Monadic concurrency libraries like lwt or async are the way to go. You can definitely build message-passing libraries on top of these, and many have. You can also build such libraries against raw threads, but I would recommen= d. None of which is to argue that you shouldn't use a binding of some non-OCaml message-passing library. I've heard excellent things about zeromq,which has bindings in opam. y On Sun, Sep 29, 2013 at 3:54 AM, Tom Ridge wrote: > Having read that lecture again, I understand that I should be using a > message passing interface written in some other language, with bindings to > OCaml. > > Thanks > > > On Saturday, 28 September 2013, Tom Ridge wrote: >> >> 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 =E9crit : >> >> > Dear caml-list, >> >> > >> >> > I have a little program which creates a thread, and then sits in a >> >> > loop: >> >> > >> >> > -- >> >> > >> >> > let f () =3D >> >> > let _ =3D ignore (print_endline "3") in >> >> > let _ =3D ignore (print_endline "hello") in >> >> > let _ =3D ignore (print_endline "4") in >> >> > () >> >> > >> >> > let main () =3D >> >> > let _ =3D ignore (print_endline "1") in >> >> > let t =3D Thread.create f () in >> >> > (* let _ =3D Thread.join t in *) >> >> > let _ =3D ignore (print_endline "2") in >> >> > while true do >> >> > flush stdout; >> >> > done >> >> > >> >> > let _ =3D 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 _ =3D ... 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 >> > >> >