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