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 5AF2E7FD1D for ; Wed, 4 Nov 2015 16:09:30 +0100 (CET) IronPort-PHdr: 9a23:mCotfxxTUJRxtxzXCy+O+j09IxM/srCxBDY+r6Qd0OoRIJqq85mqBkHD//Il1AaPBtWGrakcwLeJ+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStOU1Jz8ir/60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGx48sgs/M9YUKj8Y79wDfkBVGxnYFYO+dbzuBLfYQyK73oaGiVKw1sbSzTCuVvAX5zxuzH2/tU7/W/SH8rwQKt+EWC47qxrYBbujioXNjd/93vY3J9elqVe9T2orQZ+zoqcW4qVOeBzZOuJctoQX2tMWoBKXCxMGI6mR4QKBusFe+1fqt+u9BM1sRKiCFz0V6vUwThSiyqzgPQ3 Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f182.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARAQBuHjpWlbbfVdFeg1o0LUIGrC2BT4UvjAIhhXICgTcHPBABAQEBAQEBARABAQEBBw0JCR8wgi6CCAEBAwESEQQZARsSCwEDAQsGBQQHGh0CAiIBEQEFAQoSBhMSEId2AQMKCA2jEYExPjGLSIFqgnmHGQoZJwMKVoNgAQEBAQEFAQEBAQEBAQEVAQUOhkeEfoUIgm2BQwWGCwyMUINhhR2IBoFaSJYtgiUSJIEXESeCLyOBXj00hTQBAQE X-IPAS-Result: A0ARAQBuHjpWlbbfVdFeg1o0LUIGrC2BT4UvjAIhhXICgTcHPBABAQEBAQEBARABAQEBBw0JCR8wgi6CCAEBAwESEQQZARsSCwEDAQsGBQQHGh0CAiIBEQEFAQoSBhMSEId2AQMKCA2jEYExPjGLSIFqgnmHGQoZJwMKVoNgAQEBAQEFAQEBAQEBAQEVAQUOhkeEfoUIgm2BQwWGCwyMUINhhR2IBoFaSJYtgiUSJIEXESeCLyOBXj00hTQBAQE X-IronPort-AV: E=Sophos;i="5.20,243,1444687200"; d="scan'208";a="186049917" Received: from mail-io0-f182.google.com ([209.85.223.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 04 Nov 2015 16:09:29 +0100 Received: by iody8 with SMTP id y8so56277661iod.1 for ; Wed, 04 Nov 2015 07:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TCIWYe5pRsKFnv2/ShvvpkWnKV/nBJcIWIztd7vOD3Y=; b=tWt86ydrUwuEGWIovSgqG1qmVkK71qQvWb06bSGH/cdZDTIlugr2kEgQv1q+5lckI7 owhPGH7VXt6plJt5q8qxSBO4KU9TUl+pHm82wLKIdANgKeFvKm3dDznJ7jn7drOi2rwC H0dHtZM+z6lL46zHCHubGYuYBDzFeUrLONFSeu0SmWNIWFwzkshaCdWG8fGjx4q4O5dF AfjXxo7xpgB64HtytMuBDyhfRGWwlZ2EE1Tz/XGk0rWbi3kctbHusqncw9M+Gw0H9P7D vHPzoO1OJJqBHxC/pOCx8hFGDMFGQaLf5h7EHE+tw5gNGUqS4oKWFOv6ysDmNLCKb275 g3Vw== X-Received: by 10.107.31.138 with SMTP id f132mr3593990iof.84.1446649768231; Wed, 04 Nov 2015 07:09:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.39.200 with HTTP; Wed, 4 Nov 2015 07:08:48 -0800 (PST) In-Reply-To: <20151104124321.GA25230@annexia.org> References: <20151104124321.GA25230@annexia.org> From: Gabriel Scherer Date: Wed, 4 Nov 2015 16:08:48 +0100 Message-ID: To: "Richard W.M. Jones" Cc: caml users Content-Type: multipart/alternative; boundary=001a11409c5a8cd2490523b86511 Subject: Re: [Caml-list] Are refs volatile? --001a11409c5a8cd2490523b86511 Content-Type: text/plain; charset=UTF-8 I find the question hard to understand, so I may have missed a subtlety in the code you have shown. The purpose of volatile memory is to share memory between the current program and an unknown environment. In your exemple, the value of (quit), a boolean reference, is *not* shared, it is the value of (set_quit) that is passed to the environment. So the question *cannot* be about the accesses to the value "quit", which are clearly marked. One way to rephrase the question would be: "could the compiler assume than (set_quit) will never be called and thus optimize (!quit) to (false)?". I don't see how that could ever be correct, given that the function (set_quit) is passed to an external function. On Wed, Nov 4, 2015 at 1:43 PM, Richard W.M. Jones wrote: > Some code I wrote recently does: > > let quit = ref false in > let set_quit _ = quit := true in > Sys.set_signal Sys.sigint (Sys.Signal_handle set_quit); > Sys.set_signal Sys.sigquit (Sys.Signal_handle set_quit); > > and later on (where `tasks' is a list of long-running tasks): > > List.iter ( > fun task -> > if not !quit then task (); > ) tasks; > > This works fine. My question is, could a change to the compiler in > future cause the reference to !quit to be optimized away? And if so, > is there a way to mark it as "volatile" (in the C sense)? > > Rich. > > -- > Richard Jones > Red Hat > > -- > 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 > --001a11409c5a8cd2490523b86511 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I find the question hard to understand, so I may have= missed a subtlety in the code you have shown.

The purpose of volati= le memory is to share memory between the current program and an unknown env= ironment. In your exemple, the value of (quit), a boolean reference, is *no= t* shared, it is the value of (set_quit) that is passed to the environment.= So the question *cannot* be about the accesses to the value "quit&quo= t;, which are clearly marked.

One way to rephrase the question= would be: "could the compiler assume than (set_quit) will never be ca= lled and thus optimize (!quit) to (false)?". I don't see how that = could ever be correct, given that the function (set_quit) is passed to an e= xternal function.

On Wed, Nov 4, 2015 at 1:43 PM, Richard W.M. Jones <rich@annexia.= org> wrote:
Some code I wro= te recently does:

=C2=A0 let quit =3D ref false in
=C2=A0 let set_quit _ =3D quit :=3D true in
=C2=A0 Sys.set_signal Sys.sigint (Sys.Signal_handle set_quit);
=C2=A0 Sys.set_signal Sys.sigquit (Sys.Signal_handle set_quit);

and later on (where `tasks' is a list of long-running tasks):

=C2=A0 List.iter (
=C2=A0 =C2=A0 fun task ->
=C2=A0 =C2=A0 =C2=A0 if not !quit then task ();
=C2=A0 ) tasks;

This works fine.=C2=A0 My question is, could a change to the compiler in
future cause the reference to !quit to be optimized away?=C2=A0 And if so,<= br> is there a way to mark it as "volatile" (in the C sense)?

Rich.

--
Richard Jones
Red Hat

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a11409c5a8cd2490523b86511--