Killing threads

[bieffe62 at gmail.com]

On Apr 5, 9:48 pm, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
> On Sun, 05 Apr 2009 12:54:45 +0200, Francesco Bochicchio
> <bock... at virgilio.it> declaimed the following in
> gmane.comp.python.general:
>
> > If yor threads are not set as 'deamons' using Thread.setDaemon method,
> > then your main program at its termination should call Thread.join for
> > each of the thread spawned, otherwise the whole process will not quit.
>
>         .join() alone won't do anything but wait for the thread itself to
> quit -- which means one still has to signal the threads to commit
> suicide.
>

Yes. Mine was an 'additional suggestion' to the ones that the OP
already received.
I guests that was not clear enough ...

.. follows a nice explanation on methods to stop threads that I was
too lazy to write ...

>
>         If the thread has the capability to become blocked on some operation
> (say a socket read without timeout), none of these solutions will work.
> That just leaves setting the threads daemonic at the start -- which
> indicates the runtime may brutally kill them when the main program
> exits.
>

You know, this bugger me a little. I know that killing threads is hard
in any language
(I'm facing now the issue in a C++ program I'm writing at work),
expecially doing in
a platform-independent way, but Java managed to do it. Now python is
in many ways an
higher level language than Java, but when it comes to threading I feel
it lacks something.
I know that often it is not too hard to avoid blocking reads, and you
can always use subprocesses that
with the new multiprocessing module are almost as easy as threads, but
still ...

Ciao
-----
FB