On Jan 4, 12:31 pm, Fuzzyman <fuzzy...@gmail.com> wrote: > On Jan 4, 3:31 pm, Roy Smith <r...@panix.com> wrote: > > > > > In article > > <2ebc11a5-1b45-4faa-97b9-c84f0db01...@k22g2000yqh.googlegroups.com>, > > > Fuzzyman <fuzzy...@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/ -- http://mail.python.org/mailman/listinfo/python-list
