Xavier Leroy wrote:
> > - No way to wait for one thread to finish among many (equivalent of
> > join, but taking a list of threads as argument)
> 
> This isn't supported directly in POSIX threads.  However, you can
> easily program it yourself using e.g. events: allocate a channel, have
> each thread send a message on it when it terminates, and wait for a
> message on the channel.  The good thing about this method is that you
> can put whatever you need in the message (thread ID, return value, etc).
> 
Ok, but if I wait for thread A or B and thread C stops, then I will wake
up and test 
on the channel if it is thread A or B. This means waiting in a loop. If
there are a lot of small threads with short life ... this is not very
good.

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 ?

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
?

Yet another question: What is the size of a thread in both cases:
bytecode and native.
Is 1000 threads reasonable ?
  
> > - No way to send a signal to a thread (it would be useful to make a
> > thread raise an exception from another thread).
> 
> I agree this would be nice, and can easily be implemented in the case
> of bytecode threads.  For POSIX threads, one could try using
> cancellation to handle this, but I'm not sure it can be done in a
> portable way.  For Win32 threads, I don't know how to do it.
> 

I think it is worth a try ! even if the semantic means that after
handling the exception, the thread must terminates and it will never
receive another exception of this kind.

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

>
>

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

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



-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI