> 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:14:29 MET