From: Tom Ridge <tom.j.ridge+caml@googlemail.com>
To: caml-list <caml-list@inria.fr>
Cc: Romain Bardou <romain.bardou@inria.fr>,
Benedikt Grundmann <bgrundmann@janestreet.com>
Subject: Re: [Caml-list] Thread behaviour
Date: Sat, 28 Sep 2013 20:09:12 +0100 [thread overview]
Message-ID: <CABooLwMPKnhggzjOxe5ZPWuEuiayP6Hwf+PC1TDOzqsU7rQNhQ@mail.gmail.com> (raw)
In-Reply-To: <CADbMkNPa=iQYt4fZD_vmQ-vYcEdT9NtxsFCSR0u3_9QztaBTOg@mail.gmail.com>
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
> 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>
> 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
>
>
next prev parent reply other threads:[~2013-09-28 19:09 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 [this message]
2013-09-29 7:54 ` Tom Ridge
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=CABooLwMPKnhggzjOxe5ZPWuEuiayP6Hwf+PC1TDOzqsU7rQNhQ@mail.gmail.com \
--to=tom.j.ridge+caml@googlemail.com \
--cc=bgrundmann@janestreet.com \
--cc=caml-list@inria.fr \
--cc=romain.bardou@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