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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 6B0337EE4B for ; Sun, 29 Sep 2013 09:54:29 +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.220.42; 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.220.42 as permitted sender) identity=mailfrom; client-ip=209.85.220.42; 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-pa0-f42.google.com) identity=helo; client-ip=209.85.220.42; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="postmaster@mail-pa0-f42.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEBAMLbR1LRVdwqm2dsb2JhbABZgz9Srh+KFIhCgRgIFg4BAQEBAQYLCwkUKIIlAQEEAUABASwMBAsBCgsNDSEiEgEFAQoSBhMSh2EBAwkGDJxeiwyEUAEFg2AKGScDColkAwMGAYx4gk6ELZgCgS+OYBgpgWKCbDs X-IPAS-Result: AsEBAMLbR1LRVdwqm2dsb2JhbABZgz9Srh+KFIhCgRgIFg4BAQEBAQYLCwkUKIIlAQEEAUABASwMBAsBCgsNDSEiEgEFAQoSBhMSh2EBAwkGDJxeiwyEUAEFg2AKGScDColkAwMGAYx4gk6ELZgCgS+OYBgpgWKCbDs X-IronPort-AV: E=Sophos;i="4.90,1003,1371074400"; d="scan'208";a="28444456" Received: from mail-pa0-f42.google.com ([209.85.220.42]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Sep 2013 09:54:27 +0200 Received: by mail-pa0-f42.google.com with SMTP id lj1so4550184pab.29 for ; Sun, 29 Sep 2013 00:54:26 -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:date:message-id:subject :from:to:content-type; bh=3MSbwTG6RtVzJnni1IjWMkQjmn2+RfS0SvQpMobGYIA=; b=lslAVHH9bTOz31c9giBaURGrwQKP2aBautCAcUpatVFPS579rtHhMzlrrFFt6rhR7A Kbtk9JT4jzHLHBwzX6SYboshjgOSRcOVCKtbKA7B1zm5qlM/9qp3pXOVlMzlgyQqFpHd +bQyx6RIG9dx4cT3dpqLM1Llj+j3Pv+u9uie0YDh0g2Y9golg5J/V1EezlWydLo2MgJx HUaPGKyCnQqWMX/1fqMJZpH7wGzy7khUvvGkM/q76IqHNXyqrTVFElf5g5Xo+ortf9wl zBiT8o1v556NlQTbpdwzhZzDP9fufwtePyq/g0q7WrB7gAOAVvADsuPnDjW8ljuIACKG qv0w== MIME-Version: 1.0 X-Received: by 10.66.7.102 with SMTP id i6mr167340paa.149.1380441266260; Sun, 29 Sep 2013 00:54:26 -0700 (PDT) Sender: tom.j.ridge@googlemail.com Received: by 10.70.79.136 with HTTP; Sun, 29 Sep 2013 00:54:26 -0700 (PDT) In-Reply-To: References: <52455D91.6000304@inria.fr> Date: Sun, 29 Sep 2013 08:54:26 +0100 X-Google-Sender-Auth: TUKXW5OYzwC22AoyCvs50vy_pjY Message-ID: From: Tom Ridge To: caml-list Content-Type: multipart/alternative; boundary=bcaec520e8e14f14d504e7810797 Subject: Re: [Caml-list] Thread behaviour --bcaec520e8e14f14d504e7810797 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 agai= n. > > 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 fr= om > >> > 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 t= he > >> > while loop then f's output gets printed pretty quickly. But why shou= ld > >> > 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 t= he > >> 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 > > > > > --bcaec520e8e14f14d504e7810797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Having read that lecture again, I understand that I should be using a messa= ge passing interface written in some other language, with bindings to OCaml= .=A0

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
<bgrundmann@janestreet.com> wrote:
> The ticker thread will cause yields which will be honored on the next<= br> > allocation of the thread that currently has the caml lock. =A0That sai= d we
> have seen that sometimes the lock is reacquired by the same thread aga= in.
> So there are some fairness issues.
>
>
> On Fri, Sep 27, 2013 at 11:27 AM, Romain Bardou <romain.bardou@inria.fr>
> 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
>> > =A0 let _ =3D ignore (print_endline "3") in
>> > =A0 let _ =3D ignore (print_endline "hello") in
>> > =A0 let _ =3D ignore (print_endline "4") in
>> > =A0 ()
>> >
>> > let main () =3D
>> > =A0 let _ =3D ignore (print_endline "1") in
>> > =A0 let t =3D Thread.create f () in
>> > =A0 (* let _ =3D Thread.join t in *)
>> > =A0 let _ =3D ignore (print_endline "2") in
>> > =A0 while true do
>> > =A0 =A0 flush stdout;
>> > =A0 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 ou= tput from
>> > f to show up as well. If you wait a while, it does. But you h= ave to
>> > wait quite a while.
>> >
>> > What am I doing wrong here? I notice that if I put Thread.yie= ld in the
>> > while loop then f's output gets printed pretty quickly. B= ut why should
>> > the while loop affect scheduling of f's thread?
>> >
>> > Thanks
>> >
>>
>> OCaml's thread, unfortunately, are kind of cooperative: you ne= ed to
>> yield explicitly. Note that you will obtain an even different (wor= se)
>> result with a native program. I observed this myself without looki= ng at
>> the thread code itself so maybe there is actually a way to
>> "automatically yield" but as far as I know there is no w= ay 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 developin= g
>> (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. =A0Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginner= s
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
--bcaec520e8e14f14d504e7810797--