ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have a a python app which reads in data from a bluetooth module. I have an infinite loop as the data is continuous, but i want the user to be able to break out of it if he so wishes to close the program, rather than using ctrl+C
eg, "Do you want to quit? y/n?"
now i cant use input() as it just waits for a key press - i want the loop to be still running.
This is classic multiprocessing question. There are several architectures that could be used.
I guess the first question is whether this is unix or windoze. If unix, the simplest might be to use a separate process, then when the user wants to quit, the process group could be sent a signal (kill).
in your main loop
use select.select on sys.stdin
then if a key comes in or ^C or a sig 15 is sent to your process it will ask, but IF you are using a process ,it will hang in the background waiting for input.
## no wait arguments, I dont have the book open so dont ding my syntax
if select.select ((sys.stdin,"",""))
ch=sys.stdin.read() (one or more char's avaible in buffer)
except termsig handler (look up exceptions)
except some other error...
The server loop runs a daemon listening all time to the client.
The client ask the user about leaving the application.
When the user say Y, send a string to the server and sys.exit(0)
oooh...I've written several "servers" with a terminate option you have to be careful about when you can respawn and dangling multiple clients, as well you may have to muck some deep level socket options (aka TCP wait) and functionality. I hadnt mentioned that as its kinda a pain, and I felt the originator of the thread is just recently coming to python. BUT if you stick to one of the newer-predefined class templates its not too bad. (or you've done sockets in C) Incidentally, I daemonize simply by sh MyPython.py &, but usually keep a term window open for the process while I'm debugging or adding functionality, the main issue with threading is gui/stdio access.