On Wed, 2018-01-31 at 22:15 +0000, Arek via Digitalmars-d-learn wrote: > […] > Assuming your're talking about threads: there's no secure method > of forcing the thread to stop. Threads share the state (eg. can > hold the locks) and killing them is always risky.
I am indeed talking threads not OS processes. I just like working with (processes|tasks) submitted to a thread pool, but this can lead to jargon use problems. > If your threads are blocked reading the socket, you probably can > close these sockets and exit after the read error. The problem is actually a thread blocked in an inotify blocking read. As both Steven and yourself have pointed out I am going to have to use a timeout to check the state of the application. > Another way is to use atomic flag indicating that thread needs to > be interrupted. > After any blocking operation, the thread have to check this flag > and finish the job. > It's good to use timeouts (eg socket timeout) in such scenario > (if possible). I guess there is a choice here between shared memory to set the termination flag, or using an input channel and sending the termination message. I think the latter may be preferable, and certainly more consistent with how the other threads terminate. Thanks to you and Steven for confirming what I had been fearing, but wondered if there was an easier (albeit less theoretically sound) one. -- Russel. =========================================== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part