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;
Thread.exit();
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
-- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: Gerd.Stolpmann@darmstadt.netsurf.de (privat) Germany ----------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Wed Feb 16 2000 - 10:45:20 MET