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 20C857EE4B for ; Sat, 28 Sep 2013 21:09:48 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of tom.j.ridge@googlemail.com) identity=pra; client-ip=209.85.192.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="tom.j.ridge@googlemail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of tom.j.ridge@googlemail.com designates 209.85.192.179 as permitted sender) identity=mailfrom; client-ip=209.85.192.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="tom.j.ridge@googlemail.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@mail-pd0-f179.google.com) identity=helo; client-ip=209.85.192.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="postmaster@mail-pd0-f179.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYCABopR1LRVcCzlGdsb2JhbABZgz9SrhaSVIEaCBYOAQEBAQcLCwkSKoIlAQEFQAEBLAsBDwEKCw0NISISAQUBChIGExKHYQEDDwycLYsMhFABBYNyChknAwqJZAaMf4IfhFqYAoEvjl8YKYFigmw7 X-IPAS-Result: AkYCABopR1LRVcCzlGdsb2JhbABZgz9SrhaSVIEaCBYOAQEBAQcLCwkSKoIlAQEFQAEBLAsBDwEKCw0NISISAQUBChIGExKHYQEDDwycLYsMhFABBYNyChknAwqJZAaMf4IfhFqYAoEvjl8YKYFigmw7 X-IronPort-AV: E=Sophos;i="4.90,1000,1371074400"; d="scan'208";a="28417805" Received: from mail-pd0-f179.google.com ([209.85.192.179]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Sep 2013 21:09:34 +0200 Received: by mail-pd0-f179.google.com with SMTP id v10so3973639pde.10 for ; Sat, 28 Sep 2013 12:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=XYV8GoK+L60hyC5TqoeOvO1y8KAZlvk4fjjuOD1oft8=; b=x02MmT/pzWaT3t/n2nreLpzMbBU5MPCG22cGqBdhVafUTMOKC6ZLvXRdQ9LuH+g7J+ c2pvyIuTA5TaIrhjLdh7nCZdxlrftZmI8kEpWIc4R6ry/TcbyReS9cl7pg/u2qyEZmuu emvjJc8pn38WKr9Tvn4p4XbqqOWfpjMoCWZF+kyGSd6raeRWpA7d9InCLk6POt+aEIe5 LGXyfH4FcU/NPlV7uaFgchaRV6d2V7EbPjGfqTQRPfa20p/kcbCMk661CZG3jZWtw0ND neeAsGVnKFG9qNU88izz4yTh1ww4HyQdINiOrFG1inMyXiNoOpF0OjYj4q5lyz5vArTH hiSA== X-Received: by 10.68.101.225 with SMTP id fj1mr14596650pbb.8.1380395372221; Sat, 28 Sep 2013 12:09:32 -0700 (PDT) MIME-Version: 1.0 Sender: tom.j.ridge@googlemail.com Received: by 10.70.79.136 with HTTP; Sat, 28 Sep 2013 12:09:12 -0700 (PDT) In-Reply-To: References: <52455D91.6000304@inria.fr> From: Tom Ridge Date: Sat, 28 Sep 2013 20:09:12 +0100 X-Google-Sender-Auth: HDTCHG6h1Z8XFRDubino2ipPtFc Message-ID: To: caml-list Cc: Romain Bardou , Benedikt Grundmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Thread behaviour 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 loo= p: >> > >> > -- >> > >> > 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 > >