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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 70FC17F72C for ; Wed, 17 Aug 2016 05:09:40 +0200 (CEST) IronPort-PHdr: 9a23:A7yX1xc42LhBgugehl0k0lwUlGMj4u6mDksu8pMizoh2WeGdxc6/YR7h7PlgxGXEQZ/co6odzbGH6ua5CSdeuN7B6ClEK80UEUddyI0/pE8JOIa9E0r1LfrnPWQRPf9pcxtbxUy9KlVfA83kZlff8TWY5D8WHQjjZ0IufrymUrDbg8n/7e2u4ZqbO1wO32vkJ+oiZ0vv5UWJ749N0NMkcv5wgjLy4VJwM9xMwm1pIV/B1z3d3eyXuKBZziJLpvg6/NRBW6ipN44xTLhfESh0ezttvJ6j5lH/Sl6E734YF2EXiQZgAg7f7Ri8UI2inDH9s79F2SSAJ8DBaDEoQz25p/NzSRLykioAMTAR/2Tei8g2h6Ve9kHy7ydjypLZNdnGfMF1ebnQKIsX Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=pierreonf@gmail.com; spf=Pass smtp.mailfrom=pierreonf@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f171.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of pierreonf@gmail.com) identity=pra; client-ip=209.85.223.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="pierreonf@gmail.com"; x-sender="pierreonf@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of pierreonf@gmail.com designates 209.85.223.171 as permitted sender) identity=mailfrom; client-ip=209.85.223.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="pierreonf@gmail.com"; x-sender="pierreonf@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-io0-f171.google.com) identity=helo; client-ip=209.85.223.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="pierreonf@gmail.com"; x-sender="postmaster@mail-io0-f171.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArAQAx1LNXhqvfVdFehBt8B61+i0uBfRyHWAc6EgIBAQEBAQEBARIBAQEICwsJGS+CMhaCLxEdARsRDQMSCQc3AiQBEQEFAVeHdAEDF58FggeBMj4yizyBaoJbBYZgChknDVSEAgIGEJIogloFmUSGIIh7gWtOh0CFT4g6hjcTHoEPJQuBcVaBcyAyhmEBAQE X-IPAS-Result: A0ArAQAx1LNXhqvfVdFehBt8B61+i0uBfRyHWAc6EgIBAQEBAQEBARIBAQEICwsJGS+CMhaCLxEdARsRDQMSCQc3AiQBEQEFAVeHdAEDF58FggeBMj4yizyBaoJbBYZgChknDVSEAgIGEJIogloFmUSGIIh7gWtOh0CFT4g6hjcTHoEPJQuBcVaBcyAyhmEBAQE X-IronPort-AV: E=Sophos;i="5.28,529,1464645600"; d="scan'208,217";a="232786190" Received: from mail-io0-f171.google.com ([209.85.223.171]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 17 Aug 2016 05:09:39 +0200 Received: by mail-io0-f171.google.com with SMTP id m101so125304038ioi.2 for ; Tue, 16 Aug 2016 20:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=NLtS3KYo7rwiSrhKVOuPxbhbC081MMxQwwcfHAj73XE=; b=VKNOhzES9CHchiTetUXitxcSoIdwAdZC9uQNeDekWP9OuIGC93MjRbypVYkQv085kQ IHsGRgo2QY9BUY+5HzvkPVws2041fIyURiygRyTe0jwA0we1e4yCjejx4a0V+89tXNZq z5POSeSzh+qKVAL4FodrZxIpzKZAdRNbI0YIS0rTHBHIi8KIb7+Ud3hoXXiZuZSAmtdP vFR4/NQm3DW4gfoogI5rTUd2/qS1iB7P4aHgKXePcVQERcs2VFyMte/g0XoOoGP+rsrE WsGA9cM24z4bv/PeRTZNc4IBivO0YiNAJLV8oFqF/wln558qQ4svgrNeRE2f+Gbn0nrW ZiZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NLtS3KYo7rwiSrhKVOuPxbhbC081MMxQwwcfHAj73XE=; b=X20vmprddmz2kZIxJrpoX0qvqnaLfmzdr1zR8JTte0/sCWPldWkSQDLQi042zBQ4NX 2CNnuYBrfySV7p7JMC7G2zXGyQ8paFtIAtsHrZl/gxm/x7cgbtd/5XY26MStrBKleMQ7 K7zcFYcyrJCmcEEOcK0p02FqeVmc6bbJZlpeBXirb2RZUdo6R+5OICwmD+Q19KjUSs0l w1xHObNtfJUb50gCLydKb1ZdBJ2XhBt03HMTsii/+uuvoAVWS7RiI/Hf1K1hb6smtyxO FEuJ6k9qFkM03J3A1pRpVDk6In/UY11xVpYEMaeE5RVr75YvRhHkLlIcQMb4P2IV/1ZL ST2A== X-Gm-Message-State: AEkoousFM8hMgdqmHI4grOvMT+kzxkaHXFkZFZw2O0/V+pzHQgExm7ffECkmzLlcBwGPu+6ehTkZA3mNxoBGhw== X-Received: by 10.107.18.154 with SMTP id 26mr42588560ios.85.1471403377617; Tue, 16 Aug 2016 20:09:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.117.149 with HTTP; Tue, 16 Aug 2016 20:09:37 -0700 (PDT) From: =?UTF-8?Q?Pierre_M=C3=A9tras?= Date: Tue, 16 Aug 2016 23:09:37 -0400 Message-ID: To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001a113f6188a4f5b1053a3bcbc7 Subject: [Caml-list] OCaml 4.03.0 on Minix3 fails threading tests --001a113f6188a4f5b1053a3bcbc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A9tras --001a113f6188a4f5b1053a3bcbc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

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

When I run the testsuite, it blocks in deadlocks in a simple test pro= gram like lib-thread/close.ml, where a read= ing 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 h= appens with systhreads only as the lightweight threads play nicely.

$ ocamlc =C2=A0-g -vmthread -w a= unix.cma threads.cma tests/lib-threads/close.m= l -o ./program
$ .= /program
reading...
closing fd...
read returned
<= font face=3D"monospace, monospace">
$ ocamlopt =C2=A0-g -thread -w a unix.cmxa threads.cmxa t= ests/lib-threads/close.ml -o ./program
10.0.2.15$ ./program
reading...
^C

<= /div>
How to deal with that? What would be the best option?
<= br>
1. I can try to have a minimal OCaml environment on Minix3 fo= r the moment and adapt the testsuite Makefiles not to run if threading is n= ot 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. Thi= s would be useful only in rare situations like Minix3...

2. Because this OCaml version is linked to pthread and the system th= inks 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_THRE= AD_COOPERATIVE or __minix defines after blocking system calls. This seems t= o me a bad workaround and a source of vicious bugs...

<= div>3. Or decide building OCaml environment without pthread on Minix (./con= figure -no-pthread) but some modules that I tried to install with opam, dep= endencies of utop or core I can't remember, required systhread...
=

Any advice on how to have the best OCaml environment an= d the maximum tests passed?

Thanks
--
Pierre M=C3=A9tras
--001a113f6188a4f5b1053a3bcbc7--