caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <Gerd.Stolpmann@darmstadt.netsurf.de>
To: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>,
	caml-list@inria.fr
Subject: Re: Thread feature missing
Date: Mon, 14 Feb 2000 16:11:42 +0100	[thread overview]
Message-ID: <00021417030701.30469@ice> (raw)
In-Reply-To: <38A7B721.172F585C@univ-savoie.fr>

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                     
----------------------------------------------------------------------------



  reply	other threads:[~2000-02-16  9:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-10 13:49 Typing problem jean-marc alliot
2000-02-11 10:17 ` Pierre Weis
2000-02-12 22:34   ` Jacques Garrigue
2000-02-14  8:04     ` Thread feature missing Christophe Raffalli
2000-02-14 15:11       ` Gerd Stolpmann [this message]
2000-02-15 16:06       ` Xavier Leroy
2000-02-16 11:31         ` Christophe Raffalli
2000-02-18  9:14           ` Xavier Leroy
2000-02-21 20:38             ` skaller
2000-02-22 11:15               ` Some questions about floatting point issues jean-marc alliot
2000-02-25 16:04                 ` 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=00021417030701.30469@ice \
    --to=gerd.stolpmann@darmstadt.netsurf.de \
    --cc=Christophe.Raffalli@univ-savoie.fr \
    --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).