Thread Question

[D]

I have a client application that I want (behind the scenes) to check
and make sure a remote host is up (i.e. by ping or TCP connect). I'm
assuming that, since I want this to go on "unknowingly" to the user,
that I would put this in a thread. My question is, how would I go
about creating the thread? I have seen examples that used classes, and
other examples that just called one thread start command - when should
you use one over another? Thanks in advance.

Doug

 

[Grant Edwards]

I have a client application that I want (behind the scenes) to check
and make sure a remote host is up (i.e. by ping or TCP connect). I'm
assuming that, since I want this to go on "unknowingly" to the user,
that I would put this in a thread.
Probably.

My question is, how would I go about creating the thread?

Assuming foo is the function you want to start in a thread:

threading.Thread(target=foo).start()

I have seen examples that used classes, and other examples
that just called one thread start command - when should you
use one over another?

I'm not sure what you mean by "use classes" vs. "calling a
thread start command". My example above uses a class
(threading.Thread) to create a thread object, and then calls
its start method.

 

[D]

Thanks, Grant. I apologize for not being clear on what I meant by
using "classes". This is an example of what I was referring to:
http://www.wellho.net/solutions/python-python-threads-a-first-example.html

See the second (threaded) example.

Doug

 

[Felipe Almeida Lessa]

Em Ter, 2006-02-28 às 20:24 +0000, Grant Edwards escreveu:

I'm not sure what you mean by "use classes" vs. "calling a
thread start command". My example above uses a class
(threading.Thread) to create a thread object, and then calls
its start method.

# He meant calling direct vs. subclassing. In your example you called
the Thread class directly, but you could have subclassed it.

# In your case, Edwards, I'd prefer subclassing because then you could
put some states in the class. A (bad) example:

class Foo(Thread):
def __init__(self):
Thread.__init__(self)
self.alive = False
self.running = True

def run(self):
while self.running:
self.alive = ping('myhost')
sleep(10)

def stop(self):
self.running = False

# Then you could:

a = Foo()
do_something()
print a.alive
do_something_more()
print a.alive
finish_everything()
print a.alive
a.stop()
# quit

--
"Quem excele em empregar a força militar subjulga os exércitos dos
outros povos sem travar batalha, toma cidades fortificadas dos outros
povos sem as atacar e destrói os estados dos outros povos sem lutas
prolongadas. Deve lutar sob o Céu com o propósito primordial da
'preservação'. Desse modo suas armas não se embotarão, e os ganhos
poderão ser preservados. Essa é a estratégia para planejar ofensivas."

-- Sun Tzu, em "A arte da guerra"

 

[Grant Edwards]

Thanks, Grant. I apologize for not being clear on what I
meant by using "classes". This is an example of what I was
referring to:
http://www.wellho.net/solutions/python-python-threads-a-first-example.html

Ah, I see. I had forgotten that people subclass Thread like
that. It's mostly just a matter of style. There aren't any
practical differences that I can think of.

 

[Felipe Almeida Lessa]

Em Ter, 2006-02-28 às 20:38 +0000, Grant Edwards escreveu:

Ah, I see. I had forgotten that people subclass Thread like
that. It's mostly just a matter of style. There aren't any
practical differences that I can think of.

Within a class you can maintain lots of internal states and make it
easily changable by other threads. Sure, you could archive this with
functions, but IMHO it's not pythonic. But for simple cases both would
suffice.

--
"Quem excele em empregar a força militar subjulga os exércitos dos
outros povos sem travar batalha, toma cidades fortificadas dos outros
povos sem as atacar e destrói os estados dos outros povos sem lutas
prolongadas. Deve lutar sob o Céu com o propósito primordial da
'preservação'. Desse modo suas armas não se embotarão, e os ganhos
poderão ser preservados. Essa é a estratégia para planejar ofensivas."

-- Sun Tzu, em "A arte da guerra"

 

[Grant Edwards]

# He meant calling direct vs. subclassing. In your example you called
the Thread class directly, but you could have subclassed it.

Yup. I should have realized that.

# In your case, Edwards, I'd prefer subclassing because then you could
put some states in the class. A (bad) example:

[...]

Good example.

It's probably bad style, but in my programs the "state info"
like that usually ends up being global variables since it's
also "attached" to thinks like GUI buttons and indicators. I
never have more than one instance of the thread, so I can get
away with it. If you need multiple instances of stateful
threads, you really do want to subclass Thread.

 

[Kent Johnson]

My question is, how would I go
about creating the thread? I have seen examples that used classes, and
other examples that just called one thread start command - when should
you use one over another?

For simple use it doesn't matter. Use a class when you want to add more
state or behaviour - for example you might want a flag that tells the
thread to stop, or a Queue to communicate with the thread. A class might
be more convenient in these cases.

IOW if you can write it as a single function it doesn't matter much
which form you use; for more complex usage you may want a class.

Kent

 

[D]

Guys - I appreciate the clarification. So it looks like they used a
class for the ping thread because they were a) running multiple
instances of the thread concurrently and b) needing to keep track of
the state of each instance, correct? I believe that in my case, since
I will be just running one instance of the thread to ensure that the
remote system is functioning properly, that the single statement should
work just fine.

 

[Aahz]

For simple use it doesn't matter. Use a class when you want to add more
state or behaviour - for example you might want a flag that tells the
thread to stop, or a Queue to communicate with the thread. A class might
be more convenient in these cases.

IOW if you can write it as a single function it doesn't matter much
which form you use; for more complex usage you may want a class.

OTOH, always subclassing requires less thinking.

 

[Just]

OTOH, always subclassing requires less thinking.

Same for never subclassing

I always felt that subclassing Thread is very unpythonic. It seems like
an unfortunate leftover Javaism (much of threading.py was inspired by
Java, but I don't need to tell you that). If I need some state, I create
my own class, with a reference to the Thread object if needed. Has-a vs.
is-a.

Just

 

[Jarek Zgoda]

Just napisa³(a):

I always felt that subclassing Thread is very unpythonic. It seems like
an unfortunate leftover Javaism (much of threading.py was inspired by
Java, but I don't need to tell you that). If I need some state, I create
my own class, with a reference to the Thread object if needed. Has-a vs.
is-a.

For me, it's not a "javaism", but "delphism" (since I know
Delphi/ObjectPascal much better than Java). In fact, in most OO
languages I know, threads are modeled as classes. Followning common
practice in this matter makes sense when you program in many languages -
your threads will be always classes with similar repertoire of methods
and attributes.