Re: Thread feature missing

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> 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