> If only the main thread can receive KeyboardInterrupt, is there any > reason why you couldn't move the functionality of the Read thread into > the main thread? It looks like it's not doing any work, just waiting > for the Proc thread to finish. > > You could start the Proc thread, do the current Read thread > functionality until the interrupt occurs, put the apporpriate message > in the queue, and then wait for the Proc thread to finish.
It is already doing that. You will notice that the Proc() function is called by a threading.Thread instance so Proc() is running in a thread, but the Read() function is being called by the main thread right after this. It DOES work with the Ctrl + C, but i can find no way at all of closing down the script from within the Proc() thread. The relevant bit of code is: t = MyThread(Proc, queue, sys.stderr, None) Read(queue, sys.stdin, sys.stderr) In the end, the problem is that i am trying to multiplex IO and other operations. In UNIX i would use select with the input file descriptor and an anonymous pipe for the extra commands to achieve this without any threads, but this script needs to run primarily on a windows box and i would like to use it on UNIX too. I thought i could use threads to achieve the IO Multiplexing in python, but it seems not or at least not simply. How do people usually manage IO multiplexing (not just using sockets) cross platform in python? I only need to multiplex two sources really: * Input file or stdin * A input event queue This will have messages injected from various locations: timers, the processing thread itself, and possibly from a single GUI thread at a later point in time. Though i can foresee that at some point in the future i may also need to multiplex those two above and some sockets (For a server with a few clients). I was thinking of looking at some asynchronous IO libraries for python on Windows + UNIX, any suggestions (Must include more than just sockets)? -- http://mail.python.org/mailman/listinfo/python-list