Thread communication
via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Wed Aug 5 07:31:18 PDT 2015
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...
More information about the Digitalmars-d-learn
mailing list