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 A5BF37EE4B for ; Wed, 2 Oct 2013 12:37:20 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of wojciech.meyer@gmail.com) identity=pra; client-ip=209.85.212.174; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of wojciech.meyer@gmail.com designates 209.85.212.174 as permitted sender) identity=mailfrom; client-ip=209.85.212.174; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f174.google.com) identity=helo; client-ip=209.85.212.174; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="postmaster@mail-wi0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYDAGz2S1LRVdSulGdsb2JhbABYgz9Srj2KFIhEgRAIFg4BAQEBBwsLCRIqgiUBAQQBQAEbEgsBAwELBgUEBw0NISIBEQEFAQoSBhMSh2EBAwkGDJ4wjFKDCoQnChknAwoGXokAAQUMj0EEB4QjA5d/gS+OYRgphE87 X-IPAS-Result: AlYDAGz2S1LRVdSulGdsb2JhbABYgz9Srj2KFIhEgRAIFg4BAQEBBwsLCRIqgiUBAQQBQAEbEgsBAwELBgUEBw0NISIBEQEFAQoSBhMSh2EBAwkGDJ4wjFKDCoQnChknAwoGXokAAQUMj0EEB4QjA5d/gS+OYRgphE87 X-IronPort-AV: E=Sophos;i="4.90,1018,1371074400"; d="scan'208";a="35235760" Received: from mail-wi0-f174.google.com ([209.85.212.174]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 02 Oct 2013 12:37:19 +0200 Received: by mail-wi0-f174.google.com with SMTP id hj3so7040905wib.1 for ; Wed, 02 Oct 2013 03:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NlvdWqLoOehWrWFmEq3qiytRWoct0rxxYd8Jvp/eCGk=; b=DD4cvd4Og3zX58JxPNIZHiChKzYPTYdiXuqTN0ef5d9cSzG7gM2BgsBIJF65p6NjNl Mb8iC+qPgY9mOZqBKjIDr9BEUWhlnniSug0CJp97+2KE5zI/x/VDzLxwl3lVeyFMxelg jmB7vgqi6+NrT8q0b3OSQYI7BOtDWu7pehNt3Epsdw74XM8/rThB7bo9OXyc/fuZeczR h7dgt9b9RR3YKkvDYHVbAVggM92QD7xYkRCUjINBqp4X6wDlav7W7M4V+gR4FkaL7kzm UtQVaj0rH2LN4dkSwKFlv4jJcNv/q7S/dxd4dv+rqo5L6Qdej++Qs1+FDCft2RSADPNB nbkQ== MIME-Version: 1.0 X-Received: by 10.194.175.193 with SMTP id cc1mr1052155wjc.54.1380710239788; Wed, 02 Oct 2013 03:37:19 -0700 (PDT) Received: by 10.216.255.143 with HTTP; Wed, 2 Oct 2013 03:37:19 -0700 (PDT) In-Reply-To: <524A573B.4030903@laposte.net> References: <524941CC.1080906@inria.fr> <524A573B.4030903@laposte.net> Date: Wed, 2 Oct 2013 11:37:19 +0100 Message-ID: From: Wojciech Meyer To: Pierre Chambart Cc: Xavier Leroy , Caml List Content-Type: multipart/alternative; boundary=089e01419d1e61664e04e7bfa739 Subject: Re: [Caml-list] Thread behaviour --089e01419d1e61664e04e7bfa739 Content-Type: text/plain; charset=ISO-8859-1 Agreed here, but it does not preclude of using very lightweight alternative based on system threads like parmap or functory for the parts have a high degree of parallerism. (and of course only if your program allows to do this) On Tue, Oct 1, 2013 at 6:01 AM, Pierre Chambart wrote: > On 30/09/2013 05:18, Xavier Leroy wrote: > > On 2013-09-27 12:10, Tom Ridge wrote: > >> I have a little program which creates a thread, and then sits in a loop: > >> [...] > >> When I run the program I get the output: > >> > >> 1 > >> 2 > >> > >> and the program then sits in the loop. > > It all depends on the whim of the OS scheduler. OCaml has no control > > over it. And you shoudn't expect any kind of fairness from the OS > > scheduler, esp. Linux's, which gladly jettisons any pretense of > > fairness in the hope of getting better throughput. > Usualy, the scheduler is fair when you force all threads to run on the > same processor. > But I would still prefer the LWT way for doing message passing. > -- > Pierre > > -- > 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 > --089e01419d1e61664e04e7bfa739 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agreed here, but it does not preclude of using very l= ightweight alternative based on system threads like parmap or functory for = the parts have a high degree of parallerism. (and of course only if your pr= ogram allows to do this)


O= n Tue, Oct 1, 2013 at 6:01 AM, Pierre Chambart <pierre.chambart@= laposte.net> wrote:
On 30/09/2013 05:18, Xavie= r Leroy wrote:
> On 2013-09-27 12:10, Tom Ridge wrote:
>> I have a little program which creates a thread, and then sits in a= loop:
>> [...]
>> When I run the program I get the output:
>>
>> 1
>> 2
>>
>> and the program then sits in the loop.
> It all depends on the whim of the OS scheduler= . =A0OCaml has no control
> over it. =A0And you shoudn't expect any kind of fairness from the = OS
> scheduler, esp. Linux's, which gladly jettisons any pretense of
> fairness in the hope of getting better throughput.
Usualy, the scheduler is fair when you force all threads to run on th= e
same processor.
But I would still prefer the LWT way for doing message passing.
--
Pierre

--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://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

--089e01419d1e61664e04e7bfa739--