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 5604A7EE4B for ; Mon, 7 Oct 2013 16:49:34 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.4; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsCAJjIUlLU4w8EeWdsb2JhbABZgz+8MIU8gR4WDgEBCQsLCTyCJQEBBAEyAUsLCxgJJQ8FKDSHcwEMCgiveh+KI4x/gh86gx+BBAOYAIEwhHOPBA X-IPAS-Result: ArsCAJjIUlLU4w8EeWdsb2JhbABZgz+8MIU8gR4WDgEBCQsLCTyCJQEBBAEyAUsLCxgJJQ8FKDSHcwEMCgiveh+KI4x/gh86gx+BBAOYAIEwhHOPBA X-IronPort-AV: E=Sophos;i="4.90,1050,1371074400"; d="scan'208";a="35916725" Received: from mout.web.de ([212.227.15.4]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 07 Oct 2013 16:49:32 +0200 Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0Mf0a9-1V9bpk14sz-00Obiy for ; Mon, 07 Oct 2013 16:49:33 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1VTC7o-0000cs-J1 for caml-list@inria.fr; Mon, 07 Oct 2013 16:49:32 +0200 Date: Mon, 7 Oct 2013 16:49:32 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20131007144932.GA2035@frosties> References: <52455D91.6000304@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:VFZhZyI1cM6Kn8CVA6AsVJRSA4W+M2KsM9aATBCeSayxIO5PBj9 WKCC8aVx2DtNA1jMvt861HE49i2Np7fOe6h1pXlfdozgeKEATU2nU7WPgbrxSGs5CR06Do0 3d6WjNXg7Key6NCu6dIAO+5omybTj0I6aEdMyQhJMX3h5D455COfhZlb8cu/NbjV8MH5aIZ sgilwhov/YhBtOXWLCEAQ== Subject: Re: [Caml-list] Thread behaviour On Sat, Sep 28, 2013 at 08:09:12PM +0100, 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). Why do you need pre-emptively scheduled threads? That would mean you have threads that are more important than others. Ocaml has no priorities in its threads for that. If you want to do I/O and computation concurrently then you probably need to offload the computation into seperate processes (with their own runtime). Otherwise, because you can't give the I/O thread a higher priority, the computation threads will block the I/O a lot of the time. One way around that is to do the computations in C, without the runtime lock. That way the I/O thread can run in parallel with computations and computations can run on multiple cores. > 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 Never ever do that. You have a busy loop there that just eats up 100% cpu time. All while holding the global runtime lock. So the thread will be blocked trying to aquire the lock. > >> > > >> > 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. "let _ = ..." and "ignore" are dangerous since they don't type check. Better would be: let () = print_endline "3" in > >> Cheers, > >> > >> -- > >> Romain Bardou MfG Goswin