caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Pierre Métras" <pierreonf@gmail.com>
To: caml-list@inria.fr
Subject: [Caml-list] OCaml 4.03.0 on Minix3 fails threading tests
Date: Tue, 16 Aug 2016 23:09:37 -0400	[thread overview]
Message-ID: <CAEAcKVZD3nkTFq2UNP+k6y8QpWQDh5pBsvu0pwzDBTqD4+vTQQ@mail.gmail.com> (raw)

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

Hello,

I'm trying to port an *almost* complete OCaml port on Minix3 while learning
this system at the same time, and I'm encountering a small blocker with
threads. Minix3 does not support native pre-emptive threads. So threads
code should be cooperative yielding the control flow regularly. I've linked
the OCaml binaries to the pthread library available in /usr/pkg/lib.

When I run the testsuite, it blocks in deadlocks in a simple test program
like lib-thread/close.ml, where a reading thread is consuming what a
writing thread puts in a pipe. In fact, the reading thread blocks on the
Unix.read system call and the scheduler never gives control back to the
writing thread that should close the pipe. This happens with systhreads
only as the lightweight threads play nicely.

$ ocamlc  -g -vmthread -w a unix.cma threads.cma tests/lib-threads/close.ml
-o ./program
$ ./program
reading...
closing fd...
read returned

$ ocamlopt  -g -thread -w a unix.cmxa threads.cmxa tests/lib-threads/
close.ml -o ./program
10.0.2.15$ ./program
reading...
^C


How to deal with that? What would be the best option?

1. I can try to have a minimal OCaml environment on Minix3 for the moment
and adapt the testsuite Makefiles not to run if threading is not
pre-emptive or to to skip the threading tests. One way to do that is to
have a new define HAVE_THREAD_COOPERATIVE added to OCaml configuration.
This would be useful only in rare situations like Minix3...

2. Because this OCaml version is linked to pthread and the system thinks
that systhreads are working, I could patch the Unix module to make it more
cooperative, adding sched_yield() calls only in the cases of
HAVE_THREAD_COOPERATIVE or __minix defines after blocking system calls.
This seems to me a bad workaround and a source of vicious bugs...

3. Or decide building OCaml environment without pthread on Minix
(./configure -no-pthread) but some modules that I tried to install with
opam, dependencies of utop or core I can't remember, required systhread...

Any advice on how to have the best OCaml environment and the maximum tests
passed?

Thanks
--
Pierre Métras

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

             reply	other threads:[~2016-08-17  3:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17  3:09 Pierre Métras [this message]
2016-08-17 10:36 ` Gerd Stolpmann

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=CAEAcKVZD3nkTFq2UNP+k6y8QpWQDh5pBsvu0pwzDBTqD4+vTQQ@mail.gmail.com \
    --to=pierreonf@gmail.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;
as well as URLs for NNTP newsgroup(s).