Re: Thread feature missing

From: Gerd Stolpmann (Gerd.Stolpmann@darmstadt.netsurf.de)
Date: Mon Feb 14 2000 - 16:11:42 MET

  • Next message: Claude Marche: "Portability of applications written in OCAML"

    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