On Sun, Dec 13, 2009 at 5:00 AM, <python-win32-requ...@python.org> wrote: > Do you have evidence that your Python code is running in multiple > threads? I.e. are you sure this isn't just ISAPI running some cleanup > work in another thread?
Oh yes. There was no doubt. I used a debugger (pydevd) to put a breakpoint at the start of each request. And then ran a section of my app which uses a frameset after limiting the app pool to 1 process. This caused several more or less simultaneous requests. The debugger showed the separate threads with the Dummy-# name label assigned by the Python threading module (plus MainThread) and I could switch back and forth between them in the debugger. I was also seeing other behavior consistent with threaded execution; there are some singleton guards in my app that were getting triggered. I also verified w/o the debugger by having each request log the thread ID via threading.currentThread() as well as the process ID. Everything I've read on ISAPI recently says it's always potentially multithreaded and that extensions must be prepared to run threaded e.g. by locking sensitive objects. At least in my case this wouldn't have been a problem if each thread ran in a separate interpreter (i.e, with separate copies of all modules.) Well, except for any un-thread-safe C extensions and GIL performance issues. For now I am using a thread lock to force sequential behavior within a process and using a multi-process application pool to achieve concurrency. thanks, -Preston _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
