A beginner's question on thread

[Timothy Wu]

I'm writing a small utility that listens for socket connections, and
also repond to user inputs via a text menu selection.

In order to respond to both the user and the incoming connections I
figure I need to use thread.

I think I would use the main thread to handle the menu and spawn a
thread which listens on a socket.

Now my question is, how do I terminate the server thread if user wants
to exit the application? If the server just sit there and listen the
thread would never terminate by itself. What kind of inter-thread
communications are available and where would I find info/tutorial on that?

Timothy

 

[Roger Binns]

Now my question is, how do I terminate the server thread if user wants

to exit the application?

The easiest way is to setDaemon(True) on the thread. See the doc for
exactly what it does.

If you want to do it in a more "proper" fashion, then you have to
make the thread do a polling loop, such as by putting a short
timeout on the sockets, and then check a variable which indicates
if you should continue, looping back if not.

It would be really nice if Python supported interrupting a thread
like Java does.

Roger

 

[Aurelio Martin]

I'm writing a small utility that listens for socket connections, and
also repond to user inputs via a text menu selection.

In order to respond to both the user and the incoming connections I
figure I need to use thread.

I think I would use the main thread to handle the menu and spawn a
thread which listens on a socket.

Now my question is, how do I terminate the server thread if user wants
to exit the application? If the server just sit there and listen the
thread would never terminate by itself. What kind of inter-thread
communications are available and where would I find info/tutorial on that?

Timothy

Well, when the user wants to exit, the main thread could open a socket
connection to the server thread, and send a special message telling it
to stop.

The server thread would have to distinguish between normal connections
from clients and special connections from the main thread.

Hope this helps

Aurelio

 

[Timothy Wu]

Well, when the user wants to exit, the main thread could open a socket
connection to the server thread, and send a special message telling it
to stop.

The server thread would have to distinguish between normal connections
from clients and special connections from the main thread.

Hope this helps

Aurelio

I've thought about doing that and I thought that was more of a hack.
Is it the proper way to handle it?

Timothy

 

[Josiah Carlson]

I'm writing a small utility that listens for socket connections, and
also repond to user inputs via a text menu selection.

In order to respond to both the user and the incoming connections I
figure I need to use thread.

I think I would use the main thread to handle the menu and spawn a
thread which listens on a socket.

Now my question is, how do I terminate the server thread if user wants
to exit the application? If the server just sit there and listen the
thread would never terminate by itself. What kind of inter-thread
communications are available and where would I find info/tutorial on that?

No need for threads.

If you have your server set up properly with asyncore, the below link
will give you an example using wxPython that will just work...

http://groups.google.com/groups?hl=...n&btnG=Search&meta=group%3Dcomp.lang.python.*

Enjoy.

- Josiah

 

[Donn Cave]

Quoth Timothy Wu <[email protected]>:
| I'm writing a small utility that listens for socket connections, and
| also repond to user inputs via a text menu selection.
|
| In order to respond to both the user and the incoming connections I
| figure I need to use thread.
|
| I think I would use the main thread to handle the menu and spawn a
| thread which listens on a socket.
|
| Now my question is, how do I terminate the server thread if user wants
| to exit the application? If the server just sit there and listen the
| thread would never terminate by itself. What kind of inter-thread
| communications are available and where would I find info/tutorial on that?

Well, that's the deal. Use threads to solve a problem, and now
you have two problems.

I'd probably do it the way Aurelio Martin proposed, with I/O to
the socket thread. It's much neater than whacking the thread,
which is the alternative.

I wouldn't necessarily use threads in the first place, though.
I think it really depends on the user interface - usually that
has to be the dispatch core of the application, and if it's
built for threads, then there you go. Typically there will be
some provision for dispatch on an I/O channel like a socket.
If you're writing your own user interface, probably just reading
and writing to the tty, and the socket thread is going to be
the one and lonely extra thread - then don't do it, I'd say.
Use select.select, or a package like asyncore or twisted or
whatever (not very familiar with that territory, I just use select.)

Donn Cave, (e-mail address removed)

 

[Timothy Wu]

Well, that's the deal. Use threads to solve a problem, and now
you have two problems.

I'd probably do it the way Aurelio Martin proposed, with I/O to
the socket thread. It's much neater than whacking the thread,
which is the alternative.

I wouldn't necessarily use threads in the first place, though.
I think it really depends on the user interface - usually that
has to be the dispatch core of the application, and if it's
built for threads, then there you go. Typically there will be
some provision for dispatch on an I/O channel like a socket.
If you're writing your own user interface, probably just reading
and writing to the tty, and the socket thread is going to be
the one and lonely extra thread - then don't do it, I'd say.
Use select.select, or a package like asyncore or twisted or
whatever (not very familiar with that territory, I just use select.)

I think Roger Binns's setDaemon() suggestion works for me. =)
Thanks for suggestion the other options. I'll take a look at asnycore or
twisted when I have time or perhaps for other projects. Since from what
I read somewhere else, it doesn't seem like Python thread's performance
is exceptional.

Timothy

 

[Timothy Wu]

Well, that's the deal. Use threads to solve a problem, and now
you have two problems.

I'd probably do it the way Aurelio Martin proposed, with I/O to
the socket thread. It's much neater than whacking the thread,
which is the alternative.

I wouldn't necessarily use threads in the first place, though.
I think it really depends on the user interface - usually that
has to be the dispatch core of the application, and if it's
built for threads, then there you go. Typically there will be
some provision for dispatch on an I/O channel like a socket.
If you're writing your own user interface, probably just reading
and writing to the tty, and the socket thread is going to be
the one and lonely extra thread - then don't do it, I'd say.
Use select.select, or a package like asyncore or twisted or
whatever (not very familiar with that territory, I just use select.)

I think Roger Binns's setDaemon() suggestion works for me. =)
Thanks for suggestion the other options. I'll take a look at asnycore or
twisted when I have time or perhaps for other projects. Since from what
I read somewhere else, it doesn't seem like Python thread's performance
is exceptional.

Timothy