Interrput a thread

[Jean-Paul Calderone]

On Jan 4, 12:31 pm, Fuzzyman <fuzzy... at gmail.com> wrote:
> On Jan 4, 3:31 pm, Roy Smith <r... at panix.com> wrote:
>
>
>
> > In article
> > <2ebc11a5-1b45-4faa-97b9-c84f0db01... at k22g2000yqh.googlegroups.com>,
>
> >  Fuzzyman <fuzzy... at gmail.com> wrote:
> > > It is unsafe to terminate an os level thread at an arbitrary point
> > > because it may be executing code in a critical section.
> > > [...]
> > > The standard advice is to use a flag and do manual checking to abort
> > > threads. This only works for fine grained operations and *doesn't*
> > > work for very coarse grained operations or where there aren't
> > > convenient places to check the flag.
>
> > Another possibility is to not use threads!  If you
>
> > 1) Need asynchronous operation
>
> > 2) Need iterruptability
>
> > 3) Can't poll for an "please stop" signal
>
> > You should look at running your "thread" as a separate process, which
> > you can send a kill signal to when you want it to go away.  You can then
> > communicate with it via pipes, sockets, shared memory segments, whatever.
>
> > Threads are a wonderful invention, but they are not a panacea for all
> > possible parallelism tasks.  Sometimes they're just the wrong tool.
>
> However some tasks / algorithms are done much better with threads than
> processes.
>
> Asynchronous operations are good for IO bound concurrency but not for
> CPU bound concurrency.
>
>

Asynchronous and threads aren't mutually exclusive.  An asynchronous
multithreading or multiprocessing library is perfectly well suited for
CPU bound concurrency.

>
> Michael Foord
> --http://www.voidspace.org.uk/