[EMAIL PROTECTED] wrote: > MrJean1 wrote: > > Did you try using the signal module? If not, a basic example is here > > <http://docs.python.org/lib/node546.html> which may need to be > > extended. > > I looks useful. I gave it a try, and the only weakness it has is that > when my process locks, it locks so badly that it doesn't respond to > CTRL-C, or any other signal. But by sending it a SIGQUIT which causes > it to dump the current state, and then kill it, I get the dump I need.
The Ctrl-C signal SIGINT is caught by Python by default and the signal handler raises a KeyboardInterrupt exception. For any other signals, the signal is caught but the signal handler is not called until Python returns to the main loop. Therefore, if some extension -like Postgresql in this case- is busy or hangs, nothing will happen until Python regains control. > > This is actually not a multi-threaded app. It's an application which > uses a SQL DB. The problem I was having was that I had a cursor which > started a transaction, and then never finished. Then some other cursor > came along and tried to perform a delete table, and they both locked > up. The cursor isn't ending it's transaction, and the transaction > prevents the delete table from being executed. Luckily Postgresql > allows me to list current activity, otherwise I would have been > scratching my head still. > > Using logging or print statements to debug this sort of things is > highly unsatisfactory. I think the way Java uses SIGQUIT is pretty > neat, are there any reasons why Python can't adopt something similar? I can not anwer that. /Jean Brouwers -- http://mail.python.org/mailman/listinfo/python-list