From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 0FFEA7EE4B for ; Fri, 27 Sep 2013 12:22:22 +0200 (CEST) Received-SPF: Neutral (mail3-smtp-sop.national.inria.fr: domain of simon.cruanes.2007@m4x.org does not assert whether or not 129.104.30.34 is permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=wyEE=TH=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="simon.cruanes.2007@m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of SRS0=wyEE=TH=m4x.org=simon.cruanes.2007@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=wyEE=TH=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="SRS0=wyEE=TH=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="SRS0=wyEE=TH=m4x.org=simon.cruanes.2007@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApABAORbRVKBaB4inGdsb2JhbABZgz+De74/Fg4BAQEBAQYWCTyCJgEFI1YQCyEhAgIPBUmIGad3kiySQIE2A5d8gTCTbw X-IPAS-Result: ApABAORbRVKBaB4inGdsb2JhbABZgz+De74/Fg4BAQEBAQYWCTyCJgEFI1YQCyEhAgIPBUmIGad3kiySQIE2A5d8gTCTbw X-IronPort-AV: E=Sophos;i="4.90,991,1371074400"; d="scan'208";a="28300896" Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 27 Sep 2013 12:22:21 +0200 Received: from emmental.inria.fr (emmental.inria.fr [128.93.0.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id D4DFB140C5705; Fri, 27 Sep 2013 12:22:20 +0200 (CEST) Date: Fri, 27 Sep 2013 12:22:19 +0200 From: Simon Cruanes To: Tom Ridge Cc: caml-list Message-ID: <20130927102219.GK1871@emmental.inria.fr> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g4MvFqI7wmANiPDo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Fri Sep 27 12:22:21 2013 +0200 (CEST)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.000013, queueID=F0962140C5707 X-Org-Mail: simon.cruanes.2007@polytechnique.org Subject: Re: [Caml-list] Thread behaviour --g4MvFqI7wmANiPDo Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Fri, 27 Sep 2013, Tom Ridge a =C3=A9crit : > Dear caml-list, >=20 > I have a little program which creates a thread, and then sits in a loop: >=20 > -- >=20 > let f () =3D > let _ =3D ignore (print_endline "3") in > let _ =3D ignore (print_endline "hello") in > let _ =3D ignore (print_endline "4") in > () >=20 > 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 >=20 > let _ =3D main () >=20 > -- >=20 > I compile the program with the following Makefile clause: >=20 > test.byte: test.ml FORCE > ocamlc -o $@ -thread unix.cma threads.cma $< >=20 > When I run the program I get the output: >=20 > 1 > 2 >=20 > 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. >=20 > 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? I believe the main lock on the GC can only be released if you allocate or call yield() explicitely. In this case, I suspect that flush does neither, so the loop goes on and the f thread starves. Please let more knowledgeable people correct me if I'm confused. Cheers, --=20 Simon --g4MvFqI7wmANiPDo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQIcBAEBAgAGBQJSRVxbAAoJEErAHQhJqmK2g34QAJXXixN/QM8t/4BUjVpHVAns GV/NgIWchHGyot10xx9KF/it3QPeiLpSkntOduhJba2jmvnXTVLEJuNBF66ib1xL R741wSvmMk0fiE9stA+bCNqThBxne4NDsO8xZi747i751Kib+IAb/jSyERh0AEOw EWLJX4/j2j4PgCIa86Q7e84jF8GocWLotqYi9scdsiODtTTggA4WHlT3/DoE/E2m NxHOQXdNO+URevy1Qw+ei4av7yjSuJzr+pAyqDcOFQ2tn9zXEWR1faZcW3vDX70q sxdYg2ZqZlyul5Nidn9XSmdaI8yCho4UaxcIyCqZWYI1ZEYOMMLdCSiXm1svjnmL ZnX+nOYmTPnfHETCjma2+fJb5JD4IeYXcu9PNqr8KfhSSYFo9IrkoagaXA+yseCp zJMZxyuX2FLMK+/kKkwo/wr3jmnMmuq6P69xWN7WOqXTFdEbnUAJJl74wwnGOxnl cfePyev+EfYHjJeqmPVKu2oiIbkzkVxq8Jb7nxna4CaF3tBRaI08eLnnWp3TrShe Iz1UdA1/HGifVmb7KT1sOEBRU//oRyZXbIANajNi0IsB4M6ZtzpBCZWlPEMejldw AvAGVCnZqDPKvSH8KmU/Q/4UeBmqU0Rb4VbRwgBbf3KWOxLXsrHymHER3Lbla8+x 4iV9ExMIQqbNELTpilXJ =tC0B -----END PGP SIGNATURE----- --g4MvFqI7wmANiPDo--