On Wednesday, 5 August 2015 at 11:23:28 UTC, Chris wrote:
The problem is that it works up to a certain extent with
receiveTimeout. However, if the input arrives in very short
intervals, all the solutions I've come up with so far
(including data sharing) fail sooner or later. New threads are
spawned faster than old ones can be given the abort signal.
There are ways to wait, till a given thread dies, say with a
shared variable isAlive `while (isAlive) {}`, but even here
I've come across problems when the input comes very fast.
You could use a thread pool, thereby limiting the number of
threads that can run at any one time. But I guess you want the
processing of new data to start as soon as possible, in which
case that wouldn't help you.
I don't know how to solve this problem, because message passing
follows a linear protocol (as far as I understand it) and
shared variables give rise to data races. Something like
pthread_kill() would indeed be useful, to terminate a thread at
random. I wonder if fibers would be an option.
D-threads seem to be based on the assumption that there is no
need to abort threads at random, any time. Or am I mistaken?
It was a conscious decision not to provide a kill method for
threads, because it is impossible to guarantee that your program
is still consistent afterwards. Maybe we can lift this
restriction if we know that the thread's main function is pure
and takes no references to mutable data, because then it can by
definition never mess up the program's state. OTOH, the GC might
be running at the time the thread is killed, which could again
lead to inconsistencies...
