This gets very hard in a gui. In my experience, _most_ of the Python code
executing in a GUI is in response to GUI messages, and this often excludes
threads.
Typically, there will be a single thread managing the GUI, and other worker
threads that do not use the GUI.
Without threads, some gui OS' have the ability to dispatch pending messages
during work - eg, when processing a "Click" message, you can dispatch other
messages waiting. However, this often makes state management very difficult
(eg, imagine processing a "button up" message before completing the "button
down" processing)
> thing to do. At any rate, the only thing that this is really needed is
for
> an emergency abort by the user.
To achieve this, I have another thread, which actually creates a button
saying "Break". The user can click on this button at any time. All this
button does is to set the Python internal "interrupted" variable. Note,
however, that this can/will not break a system call - eg, if your Python
program is in a "read" statement on a socket, and is blocked waiting for
socket data, then setting the Python interrupted flag will have no effect.
I havent looked into using signals as well to abort any sleeping OS calls.
Some of the issues you have been discussing are very interesting, and I have
interest in most of these topics myself. I would be interested to hear what
you come up with on these issues (especially the "multiple sys modules"
simulation!)
Mark.
Mark.