From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Xavier.Leroy@inria.fr>
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 C615F820A1
	for <caml-list@sympa.inria.fr>; Mon, 19 Aug 2013 09:33:00 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.89,911,1367964000"; 
   d="scan'208";a="29706205"
Received: from estephe.inria.fr (HELO [128.93.11.95]) ([128.93.11.95])
  by mail2-relais-roc.national.inria.fr with ESMTP; 19 Aug 2013 09:33:00 +0200
Message-ID: <5211CA2C.4010202@inria.fr>
Date: Mon, 19 Aug 2013 09:33:00 +0200
From: Xavier Leroy <Xavier.Leroy@inria.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: caml-list@inria.fr
References: <CAP_800r3q72mPT4L9onnvBL6X0CD63F9f-7t=GVA7GcFMrD3vw@mail.gmail.com> <520DE6F8.9000105@etorok.net> <CAP_800ouyegVh=srSK5rRXAK56Akk6DBkH5tzSnTQA7jPZHp8A@mail.gmail.com>
In-Reply-To: <CAP_800ouyegVh=srSK5rRXAK56Akk6DBkH5tzSnTQA7jPZHp8A@mail.gmail.com>
X-Enigmail-Version: undefined
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] Threads and "transaction isolation" in OCaml

On 2013-08-16 18:07, Markus Mottl wrote:
> I just wondered how much we can rely on current OCaml-semantics where
> context-switches are impossible as long as there are no allocations.
> [...]
> But, surprisingly to me, I did manage to get a failure with byte code
> + POSIX threads when running this example on Linux (Centos 6.4) via
> VMware Fusion (Mac OS X).

Bytecode and native code poll for asynchronous events (context
switches, pending signals, etc) at different program points:

- Bytecode:
    . at every function call
    . at the beginning of every iteration of a while or for loop
    . at the end of "b" in "try b with ...".

- Native:
    . at every allocation in the minor heap.

Your example has a function call in the "transaction", hence the
behavior you observe.

> Anyway, is it considered reasonably future-safe to write code of that
> sort?  I'd rather not have new compiler optimizations, etc., interfere
> with these assumptions in the near future.

There is no short-term plan to change this behavior, but no guarantee
that it will be here forever.  Caveat emptor.

- Xavier Leroy