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öger <
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öger
>
> Technische Universität Berlin
> Fakultät IV - Elektrotechnik und Informatik
> Übersetzerbau und Programmiersprachen
>
> Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin
>
> Tel.: +49 (30) 314-24890
> E-Mail: christoph.hoeger@tu-berlin.de
>
>