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 Cedexté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
This archive was generated by hypermail 2b29 : Fri Feb 18 2000 - 00:36:30 MET