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 D0CAB7FD90 for ; Thu, 29 Dec 2016 19:27:39 +0100 (CET) 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-qk0-f172.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.220.172; 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.220.172 as permitted sender) identity=mailfrom; client-ip=209.85.220.172; 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-qk0-f172.google.com) identity=helo; client-ip=209.85.220.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-qk0-f172.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AxfEYFBRKfb4zwACBDWXA5mS43dpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa64ZRSN2/xhgRfzUJnB7Loc0qyN4vymATBLuM7c+DBaKdoXCE9D0Z?= =?us-ascii?q?1X1yUbQ+e7SmTDZMbwaCI7GMkQHHRExFqcdXZvJcDlelfJqWez5zNBUj/2NA5y?= =?us-ascii?q?O/inUtWK15f/hKiO/Mj4Yx9Jnya6ebNFDIu5oB+Z4sIWm4p5NqEpyl3JpXZHdv?= =?us-ascii?q?5+2X4tL1+Jmxf6oMu9qs1N6SNV7t0o/dRBXKGyRK84QKZVFnxyPGk//szmsV/Y?= =?us-ascii?q?RguC/HYGemoTmxtMRQPC6UepDd/KriLmu78li2GhNsrsQOVsVA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAAClVGVYhqzcVdFdGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgwwBAQEBAYIKB6IQiGuON4YiAoFTB0IRAQE?= =?us-ascii?q?BAQEBAQEBAQESAQEBCAsLCR0wgjMYgh4BBAEjHQEbHQEDAQsGBQQHNwICIgERA?= =?us-ascii?q?QUBHAYTiFQBAxAIoXk/jAKCAwUBHIMKBYNUChknDVSCPAEBAQEBAQQBAQEBAQE?= =?us-ascii?q?BGQIGEoY0hGOEM4Magl0FkAKKe4F6j0WQVo4vgkkUHoEUNYEpURKDRSCCByA0i?= =?us-ascii?q?QABAQE?= X-IPAS-Result: =?us-ascii?q?A0AtAAClVGVYhqzcVdFdGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgwwBAQEBAYIKB6IQiGuON4YiAoFTB0IRAQEBAQEBAQEBAQESA?= =?us-ascii?q?QEBCAsLCR0wgjMYgh4BBAEjHQEbHQEDAQsGBQQHNwICIgERAQUBHAYTiFQBAxA?= =?us-ascii?q?IoXk/jAKCAwUBHIMKBYNUChknDVSCPAEBAQEBAQQBAQEBAQEBGQIGEoY0hGOEM?= =?us-ascii?q?4Magl0FkAKKe4F6j0WQVo4vgkkUHoEUNYEpURKDRSCCByA0iQABAQE?= X-IronPort-AV: E=Sophos;i="5.33,428,1477954800"; d="scan'208,217";a="252202602" Received: from mail-qk0-f172.google.com ([209.85.220.172]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 29 Dec 2016 19:27:38 +0100 Received: by mail-qk0-f172.google.com with SMTP id n21so273308850qka.3 for ; Thu, 29 Dec 2016 10:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VnE4KPcnPTr8RyhzIaG4T8WuFC9WJumBkPY1saq+AOo=; b=NOHlg0eucAIIgXwoP3wSscjPYdWz4KAhxMOXB+7KEoEwrLYvm04+5SF8Uf+pC+9H/8 piMKEg1cMaOUI4ZYOmrVDF/FRwhjXshHkL6PSALBlTsBwkp3vTHgSMYEoOEfu8+rSiM6 Q/2BHz5oI/9oluoaRwoVnZGdTc3Yo9VnxrDpdfFNyDH7e1fMOaKKn5wNhiQUopFIrQU6 0HGYOHR2858MO0taNAxku/pZebQKXA3lNSLlMo9Gm7y5xZAGEHXgRsV9XrLVMep04jmd fes5tv1MImP0uVpw9YWa1lmw5KzwZ5i+L01p37PlNvUmbpFQanbPFWUCvk2ORcbP1SS2 aWeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VnE4KPcnPTr8RyhzIaG4T8WuFC9WJumBkPY1saq+AOo=; b=Ku4XjOSFOX92GRwC/WOfE2B2qIWt4scIkEOe+kxZSpoLbH5ElZzWnlA73T26TIqRxZ MQWjTwi5H0WVU9ZVSd3uV4RikmemCy0+TpxtvJWYPb3DbseeS40O6mW8ol1yvgKM0oAI tRPoUmNDyrhLBjBxWHRMyiVqqSGElC883RTzT4NyXF7R8ie87Eh7qdXJGj+rk7+14pcj vCx9VHCY3gslb/kg/pYbidW/Uo3OouVOBWjN8T3gL4fe0+A3pkczVT/NkDHQZNcMwVdP S+jzjDQS8Oamsfm8kS5yCu9S9dzc9u/EIigWgpGb9sMuabAqZT+hQAqBUJy+i4f5BQ8G NvKA== X-Gm-Message-State: AIkVDXKzwNKR6bxJw+nVcPuh6NNItWVjw8F3V79gUPZfvjfsZ+B+AbTfhW5f/gChlpBKoVXSxDwxOArTNQc7yw== X-Received: by 10.55.190.6 with SMTP id o6mr27623360qkf.124.1483036057767; Thu, 29 Dec 2016 10:27:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.172.73 with HTTP; Thu, 29 Dec 2016 10:26:57 -0800 (PST) In-Reply-To: References: From: Gabriel Scherer Date: Thu, 29 Dec 2016 13:26:57 -0500 Message-ID: To: =?UTF-8?Q?Christoph_H=C3=B6ger?= Cc: caml users Content-Type: multipart/alternative; boundary=94eb2c0431c66993ab0544d03dda Subject: Re: [Caml-list] Re-entrant OCaml --94eb2c0431c66993ab0544d03dda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My understanding is that the OCaml runtime is thread-safe (and when you use native-threads you do get an OCaml process with several hardware threads), but that it uses a big runtime lock that guarantees that only one thread at a time can run OCaml code (the others are free to do whatever). You should be able to safely use existing OCaml in a multi-threaded application, but depending on how it is used it may result in a concurrency bottleneck. (I'll let more informed others comment on the state of re-entrant runtimes.) On Thu, Dec 29, 2016 at 12:46 PM, Christoph H=C3=B6ger < christoph.hoeger@tu-berlin.de> wrote: > Dear all, > > I am currently investigating a proprietary application server with an > embedded functional language. The current implementation of the language > misses several features and one particular interesting path for further > development would be to compile it to OCaml. > > There is, however, the caveat of embedding the generated code in the > application server. Right now, (compiled) programs are called directly > from the core (effectively just C-functions) and call a certain API on > the core (again, C-functions). This is possible in OCaml, too, but the > default runtime is not thread-safe. If multiple such calls are made > concurrently, I expect immediate havoc. > > Is there any project that provides a re-entrant runtime? In particular, > I would be interested in a version of libasmrun (and the corresponding > compiler) that does not rely on static variables. Instead, the required > data could be passed as an argument to each function. > > Is there any such backend currently under development? How are the > chances of mainlining? > > regards, > > Christoph > > -- > Christoph H=C3=B6ger > > Technische Universit=C3=A4t Berlin > Fakult=C3=A4t IV - Elektrotechnik und Informatik > =C3=9Cbersetzerbau und Programmiersprachen > > Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin > > Tel.: +49 (30) 314-24890 > E-Mail: christoph.hoeger@tu-berlin.de > > --94eb2c0431c66993ab0544d03dda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My understanding is that the OCaml runtime is thread-= safe (and when you use native-threads you do get an OCaml process with seve= ral hardware threads), but that it uses a big runtime lock that guarantees = that only one thread at a time can run OCaml code (the others are free to d= o whatever). You should be able to safely use existing OCaml in a multi-thr= eaded application, but depending on how it is used it may result in a concu= rrency bottleneck.

(I'll let more informed others com= ment on the state of re-entrant runtimes.)

On Thu, Dec 29, 2016 at 12:46 PM, = Christoph H=C3=B6ger <christoph.hoeger@tu-berlin.de> wrote:
Dear all,

I am currently investigating a proprietary application server with an
embedded functional language. The current implementation of the language
misses several features and one particular interesting path for further
development would be to compile it to OCaml.

There is, however, the caveat of embedding the generated code in the
application server. Right now, (compiled) programs are called directly
from the core (effectively just C-functions) and call a certain API on
the core (again, C-functions). This is possible in OCaml, too, but the
default runtime is not thread-safe. If multiple such calls are made
concurrently, I expect immediate havoc.

Is there any project that provides a re-entrant runtime? In particular,
I would be interested in a version of libasmrun (and the corresponding
compiler) that does not rely on static variables. Instead, the required
data could be passed as an argument to each function.

Is there any such backend currently under development? How are the
chances of mainlining?

regards,

Christoph

--
Christoph H=C3=B6ger

Technische Universit=C3=A4t Berlin
Fakult=C3=A4t IV - Elektrotechnik und Informatik
=C3=9Cbersetzerbau und Programmiersprachen

Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin

Tel.: = +49 (30) 314-24890
E-Mail: christoph.hoeger@t= u-berlin.de


--94eb2c0431c66993ab0544d03dda--