Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Typing problem
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gerd Stolpmann <Gerd.Stolpmann@d...>
Subject: Re: Thread feature missing
On Mon, 14 Feb 2000, Christophe Raffalli wrote:
>Have I miss something ? I found that two features (especialy the first)
>are missing in the thread library:
>- No way to wait for one thread to finish among many (equivalent of
>join, but taking a list of threads as argument)

This can be solved by a condition variable, provided that the "sub threads"
help the main thread.

let m = Mutex.create() in       (* protects c and t *)
let c = Condition.create() in
let t = ref None in             (* thread ID of the finished thread *)

Before the sub threads finish, they indicate what is happening:

Mutex.lock m;
if t = None then (              (* Signal only when the first thread finishes *)
    t := Some (Thread.self());
    Condition.signal c;
Mutex.unlock m;

The main thread waits until the signal comes:

Mutex.lock m;
Condition.wait c m;
(* Now it knows that thread t has finished *)
Mutex.unlock m;

>- No way to send a signal to a thread (it would be useful to make a
>thread raise an exception from another thread).

If you mean asynchronous signals: The POSIX thread API has the concept of
"cancellation-safeness". Threads are cancellation-safe if you can safely
cancel them, without leaving memory uninitialized. It is very hard to get
a thread cancellation-safe, because you must catch the "cancel" signal
in almost every function, and CLEAN MEMORY UP. 

I think this is the reason why you do not find a "kill" function in Thread
that works under the native compiler, too. (Raising exceptions is a similar
problem.) As far as I understood execution of O'Caml code is done in a 
relative protected environment; the runtime system sets up artificially that 
only one thread which currently executes O'Caml code runs at a time. It would
be simple to test on some signal if the time slice of a thread begins. The
problem are the pieces of code where this protected environment is left,
which is always done if a system call is going to be performed. As far as I
know the system calls return with an EINTR error code if the timer that
triggers the thread switch times out, and it *might* be possible to
catch this situation, too.

I would predict that the O'Caml developers refuse such a change, because
it adds much complexity to the runtime system. Furthermore, it makes it
harder to get rid of that protected environment in which O'Caml code runs
and which restricts the advantages of multi-threaded programming on 
multiprocessor systems.

Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail: (privat)