Re: Thread feature missing

From: Xavier Leroy (Xavier.Leroy@inria.fr)
Date: Fri Feb 18 2000 - 10:14:03 MET

  • Next message: Patrick Goldbronn - SYSCO: "Re: Portability of applications written in OCAML"

    > I think it is better to have one channel for each thread and wait
    > using Event.select that thread A or B send on their respective
    > channel. Am I right ?

    You can do that too.

    > I have another little pb which is that Many threads may be waiting
    > for A to terminate. So I could do a loop always sending on the
    > termination channel of A. But is there a better way ? A kind of
    > broadcast forever a value on a channel ?

    If you need that kind of stuff, you'd better not use the Event module
    and design your own "mailbox" mechanism using mutexes and conditions
    (as Gerd Stolpmann outlined).

    However, I would argue that a design where a thread needs to be joined
    by several other threads is broken. In most threads libraries
    (e.g. POSIX threads), you can join a thread at most once.

    > Yet another question: What is the size of a thread in both cases:
    > bytecode and native.
    > Is 1000 threads reasonable ?

    With bytecode threads, it's barely reasonable. Each thread consumes
    about 4 K of memory for its initial stack.

    With native threads, it's ways too much. E.g. LinuxThreads (or,
    really, the Linux kernel) supports 256 threads for normal users, 512
    for the super-user.

    Again, I'd argue that a design that calls for thousands of threads is
    broken. See the periodic and lively discussions on
    comp.programming.threads on this topic.

    Instead of creating lots of short-lived threads, consider having a
    reasonable number of worker threads (e.g. 10), started once and for
    all, which pick things to do from a queue of requests.

    > What I mean is that a clean interface to pthread_cleanup_push would be
    > enough
    > And probably portable (I do not know for Win32 ?)

    No, Win32 has no equivalent of POSIX cancellation handlers.

    > A Last question: How to make the GC collects an inacessible thread ?
    > The pb is that the definition of inacessible is hard for a thread:
    > it means no pointer to the thread (thats easy), but also no more
    > common mutable variables or channel : the thread can not interact
    > with the outside world. Moreover, one must also define the outside
    > world by choosing a main thread ...

    I see no way to do this.

    > All this looks hard, but it is necessary for my application ! In a first
    > approximation I will have a lot of potentialy dead thread running
    > :-(

    Then consider alternative designs for the application.

    - Xavier Leroy



    This archive was generated by hypermail 2b29 : Mon Feb 21 2000 - 18:04:30 MET