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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 321F8820A1 for ; Thu, 15 Aug 2013 23:57:15 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=74.125.82.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of markus.mottl@gmail.com designates 74.125.82.48 as permitted sender) identity=mailfrom; client-ip=74.125.82.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f48.google.com) identity=helo; client-ip=74.125.82.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-wg0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8CAA5ODVJKfVIwk2dsb2JhbABbgztQwDAIFg4BAQEBBwsLCRQEJIJrARQHHgMSEFwBAREBBQEiE4d9AQMPmX6DAIxRgwKEJQoZJw1kh3QBBQyNSYcUA5V7gWmMK4NCFimEXSA X-IPAS-Result: Ag8CAA5ODVJKfVIwk2dsb2JhbABbgztQwDAIFg4BAQEBBwsLCRQEJIJrARQHHgMSEFwBAREBBQEiE4d9AQMPmX6DAIxRgwKEJQoZJw1kh3QBBQyNSYcUA5V7gWmMK4NCFimEXSA X-IronPort-AV: E=Sophos;i="4.89,888,1367964000"; d="scan'208";a="24018603" Received: from mail-wg0-f48.google.com ([74.125.82.48]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Aug 2013 23:57:14 +0200 Received: by mail-wg0-f48.google.com with SMTP id f12so970682wgh.3 for ; Thu, 15 Aug 2013 14:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=T1mVqAGRdRIyYvG3SLFtDDdneyP+Aq7/KOYBYxj5/tQ=; b=Oj6oMb3TJP9Et15ihe26TMCeadChQ7E1RAU8Fu4leIkLuJdDF0BlB7jPXM1+KEz5n8 G/G1Xnl//ByGGJXwDkRzdnOLa/K4/qj6bYBg8IklLqt7Z6P4lsOn2DLtrZuOaE3nz/FH AIJ7nrZOCcEclIpceQMrJABbiwy8jWFa0kc9EPx+mUFOYVCOSRYEV1eivFDcTrMypKtW SiwOfOQqdYivTeduucwFhFVTtBTr6Q5TFkHU+h2KdUnIAxHUfZRDSa+XsgbxqIRbRCpa 6kHa8sDcYGdvCQjVIsGewoPtTyWJ6Q89vCuijYuM2720w30u0BNbAvCqmE2NpYWNHbpZ GE1w== MIME-Version: 1.0 X-Received: by 10.194.123.227 with SMTP id md3mr11416538wjb.17.1376603834069; Thu, 15 Aug 2013 14:57:14 -0700 (PDT) Received: by 10.194.172.169 with HTTP; Thu, 15 Aug 2013 14:57:14 -0700 (PDT) Date: Thu, 15 Aug 2013 17:57:14 -0400 Message-ID: From: Markus Mottl To: OCaml List Content-Type: text/plain; charset=ISO-8859-1 Subject: [Caml-list] Threads and "transaction isolation" in OCaml Hi, I just wondered how much we can rely on current OCaml-semantics where context-switches are impossible as long as there are no allocations. E.g. pattern-matches, array and record field assignments, etc., can be safely chained together in one "transaction" without having to fear that another thread will interrupt them. This is extremely useful for optimizing certain applications where lock acquisitions might just be too expensive. There already are some corner cases where things may be platform-dependent, e.g. calling functions tail-recursively that take more arguments than there are available CPU-registers. In that case the compiler may pass arguments by allocating blocks on the heap. But I think people that care about such obviously brittle semantics know where to be careful. 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. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com