caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Anjayan Puvananathan <apuvanan@student.math.uwaterloo.ca>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] OCaml, where art thou?
Date: Fri, 30 Mar 2001 16:51:31 +0200	[thread overview]
Message-ID: <20010330165131.A2384@pauillac.inria.fr> (raw)
In-Reply-To: <Pine.SOL.4.05.10103272142440.6267-100000@rees.math.uwaterloo.ca>; from apuvanan@student.math.uwaterloo.ca on Tue, Mar 27, 2001 at 10:38:48PM -0500

> There have been questions raised about threading in Caml under
> BeOS, but however no one has responded with authority to these.

I'm trying to catch up with my mail, but every time I respond on
caml-list some more replies pop in :-)

> I have a few more pragmatic questions related to this. BeOS
> treats threads and sockets in a fundamentally different
> (better?) way than POSIX.

I wouldn't say that the differences are fundamental -- just
significant enough to be annoying.  As much sympathy I have for BeOS,
I regret that they stopped short of providing full POSIX
compatibility.  That would make it much easier to get free software
ported to it.

> I would like to use Caml purely as
> code generator and interface the native BeOS libraries via C.
> Can I be safe is assuming that the GC facilities and in general
> Caml runtime are thread-safe.

No, neither the GC nor most of the runtime system are thread safe.

> What would be required to ensure
> thread safety, since building with -with-pthread is not an
> option on BeOS?

The "system threads" OCaml library addresses this issue by having one
global master lock that must be acquired in order to run Caml code or
call most run-time facilities, including the allocator and the GC.
This lock is released when calling C from OCaml (allowing other
threads to execute Caml code) and reacquired again before resuming
execution of Caml code.

> Could I, if desperate enough, initialize
> separate Caml runtimes by calling caml_main in different threads
> from a C main program to avoid synchronization issues?

Disaster would ensue very quickly.

> Ideally I'd like to strip any extraneous code in Caml that is associated
> with a UNIX view of the world. If OCaml is not a option, how
> about Caml Light? The language itself is worth the tradeoff in
> execution speed.

The core runtime system is ANSI C, however the threading library
(module Threads) and the OS interface (module Unix) are
system-specific.  We have implementations of these for Unix and
Windows, and as Sylvain Kerjean said volunteers are trying to build an
implementation for BeOS.

You can of course change the OCaml APIs and have BeOS-specific
BeThreads and BeSystem modules (although you'd then lose source-level
compatibility with the other systems, which I would advise against).
However, for threading, you'd still have to use the same mechanisms as
in the "system threads" library to ensure single-threadedness in the
OCaml runtime system.

Hope this clarifies the issues.

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


  reply	other threads:[~2001-03-30 14:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-28  2:19 [Caml-list] Complex Numbers David McClain
2001-03-28  3:38 ` [Caml-list] OCaml, where art thou? Anjayan Puvananathan
2001-03-30 14:51   ` Xavier Leroy [this message]
2001-03-30 23:12     ` David Fox
2001-03-31  9:31       ` [Caml-list] Using HTML as a standard GUI for Ocaml Mattias Waldau
2001-04-01 12:52         ` Fergus Henderson
2001-04-01 20:11         ` Sven LUTHER
2001-04-01 20:35           ` Bruce Hoult
2001-04-02 10:09             ` Sven LUTHER
2001-04-02 15:53               ` CREGUT Pierre FTRD/DTL/LAN
2001-04-02 19:16         ` Gerd Stolpmann
2001-04-03 18:06           ` Mattias Waldau
2001-04-02 13:21       ` [Caml-list] Threads in OCaml Xavier Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010330165131.A2384@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=apuvanan@student.math.uwaterloo.ca \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).