Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Complex Numbers
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] OCaml, where art thou?
> 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