Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Tom Ridge <tom.j.ridge+caml@googlemail.com>
To: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Thread behaviour
Date: Sun, 29 Sep 2013 08:54:26 +0100	[thread overview]
Message-ID: <CABooLwOPiZSHw+oJ7sN=VBV6kwYt4RHbcxbNcBoikb_o7hrzyQ@mail.gmail.com> (raw)
In-Reply-To: <CABooLwMPKnhggzjOxe5ZPWuEuiayP6Hwf+PC1TDOzqsU7rQNhQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4254 bytes --]

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
> <bgrundmann@janestreet.com <javascript:;>> 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 <romain.bardou@inria.fr<javascript:;>
> >
> > 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
> >> >
> >> > 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.
> >>
> >> 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
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 5798 bytes --]

  reply	other threads:[~2013-09-29  7:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-27 10:10 Tom Ridge
2013-09-27 10:22 ` Simon Cruanes
2013-09-27 10:27 ` Romain Bardou
2013-09-27 10:51   ` Benedikt Grundmann
2013-09-28 19:09     ` Tom Ridge
2013-09-29  7:54       ` Tom Ridge [this message]
2013-09-29 12:37         ` Yaron Minsky
2013-09-29 16:25           ` Tom Ridge
2013-09-29 16:46             ` Chet Murthy
2013-09-29 17:18               ` Tom Ridge
2013-09-29 17:47                 ` Chet Murthy
2013-09-30  8:24                   ` Romain Bardou
2013-10-07 14:57                     ` Goswin von Brederlow
2013-09-30  8:16       ` Romain Bardou
2013-10-01  3:32         ` Ivan Gotovchits
2013-10-07 14:49       ` Goswin von Brederlow
2013-09-30  9:18 ` Xavier Leroy
2013-09-30 15:12   ` Tom Ridge
2013-09-30 16:01     ` Török Edwin
2013-09-30 16:56     ` Gabriel Kerneis
2013-09-30 18:18       ` Alain Frisch
2013-10-01  5:01   ` Pierre Chambart
2013-10-01  7:21     ` Gabriel Kerneis
2013-10-02 10:37     ` Wojciech Meyer
2013-10-02 11:52       ` Francois Berenger
2013-10-02 11:58         ` Wojciech Meyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABooLwOPiZSHw+oJ7sN=VBV6kwYt4RHbcxbNcBoikb_o7hrzyQ@mail.gmail.com' \
    --to=tom.j.ridge+caml@googlemail.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox