Python Threading

[daniel]

Hello,
Can anyone explain the main points in working with threads in Python.
Why use threading and not Thread.I have read an article that i have to
subclass the Thread class and override some function.

[Calvin Spealman]

On 20 Sep 2006 00:27:07 -0700, daniel <da***********@gmail.comwrote:

Hello,
Can anyone explain the main points in working with threads in Python.
Why use threading and not Thread.I have read an article that i have to
subclass the Thread class and override some function.

I repeat this all the time, but the best advice I can give you about
using threads is to not use threads at all. I would point you to good
references like Threads Considered Harmful
(http://www.kuro5hin.org/story/2002/11/18/22112/860) and The Problem
with Threads (http://www.eecs.berkeley.edu/Pubs/Te...CS-2006-1.html
- With Link to PDF). It might seem an inappropriate response to your
question to simply tell you that you should not do what you are asking
how to do, but its just the case that most often anyone without
exposure to threads has little or no understanding on just how bad
they are for many of the tasks they will be used for. Threads are
difficult to control, impossible to predict, and simply one of the
most over used, least understood causes of buggy, unmaintainable
software in the whole spectrum of development techniques.

As alternatives, look into what tasks can spawn into other processes,
asyncronous programming (a'la Twisted -
http://www.twistedmatrix.com/), and co-routine and similar facilities,
such as the tasklets of Stackless and two-way generators now included
with Python.

[Fredrik Lundh]

Dennis Lee Bieber wrote:

... slightly
simpler to use without subclassing (at the simplest level, you just pass
the function that is to be run, and a list of the arguments/parameters
it needs, to the threading creation class).

that's exactly how thread.start_new_thread(func, args) works, of course,
so I'm not sure that's much of an argument.

</F>

[Bryan Olson]

Calvin Spealman wrote:

I repeat this all the time, but the best advice I can give you about
using threads is to not use threads at all.

Might as well get with the times and ignore that advice.

I would point you to good
references like Threads Considered Harmful
(http://www.kuro5hin.org/story/2002/11/18/22112/860)

Note that it's "poster boy" for multiple processes
now uses multiple threads.

and The Problem
with Threads
(http://www.eecs.berkeley.edu/Pubs/Te...CS-2006-1.html
- With Link to PDF).

The author's alternatives to threads are not available
in Python. Many Pythoners do similar things with threads,
such as use the message-passing style via the queue module.

It might seem an inappropriate response to your
question to simply tell you that you should not do what you are asking
how to do, but its just the case that most often anyone without
exposure to threads has little or no understanding on just how bad
they are for many of the tasks they will be used for. Threads are
difficult to control, impossible to predict, and simply one of the
most over used, least understood causes of buggy, unmaintainable
software in the whole spectrum of development techniques.

Threads require some study and understanding, but they work
great once one learns to use them.

As alternatives, look into what tasks can spawn into other processes,

Unfortunately one cannot share Python objects between processes.
POSH may change that, but it looks to be stuck in alpha.

asyncronous programming (a'la Twisted -
http://www.twistedmatrix.com/),

I find asynchronous programming much harder to manage than
threads, except for fairly simple applications where neither
one is hard.

and co-routine and similar facilities,
such as the tasklets of Stackless and two-way generators now included
with Python.

Those fail at simple things such as having two of them each
waiting at a blocking call.
--
--Bryan

[Bryan Olson]

daniel wrote:

Can anyone explain the main points in working with threads in Python.

They are system threads, so the main points are much like in
other languages. Examine how thread.lock works, and look up the
queue module.

Why use threading and not Thread.

There's no reason not to use thread, but threading adds
some useful items, such as setDaemon(), condition variables,
semaphores, and maybe rlocks. Try to avoid using the timeout
argument on condition variables if efficiency matters; Event and
queue.queue are implemented on top of condition variables, so
same deal.

I have read an article that i have to
subclass the Thread class and override some function.

You can, but that's the hard way. The following snippet runs
func(arg1, arg2) in a daemon thread:

import threading
# ...

t = threading.Thread(target=func, args=(arg1, arg2))
t.setDaemon(True)
t.start()
--
--Bryan