On Tue, Dec 1, 2009 at 5:33 AM, Mark Hammond <skippy.hamm...@gmail.com> wrote: > On 1/12/2009 9:13 AM, Preston Landers wrote: >> >> I just thought I'd follow up on my original post about IIS. We >> decided to go ahead and use isapi-wsgi and so far the results are very >> good. It won't go into official production for a while but it looks >> very promising. In order to avoid the threading issue (we do in fact >> use mutable module level variables) we are using the "simple" >> (non-threaded) base class. To achieve concurrency we're using the IIS >> "web garden" feature, which is the config setting Randy mentioned to >> allow multiple worker processes per application pool. We're >> configuring the app pool through ADSI, the same way Python-ISAPI >> configures itself. > > Awesome - thanks for the update. I've CCd the isapi-wsgi list for their > info.
I'm running into a problem where it looks like threading is cropping up again, even with the 'simple' WSGI base class. What I am looking for is a way to completely shut off the possibility of multithreading, as my app is not thread safe. I'm using multiple IIS worker processes for concurrency. Most requests seem to be spaced out between different IIS worker processes as desired. However in some cases with closely timed requests I'm seeing two separate threads within the same process handling the requests. I verified this with and without pydev debugging extensions for Eclipse. One thread is labeled MainThread and the other is Dummy-4 or something similar. It looks like the Dummy label is created by threading.py _DummyThread. But I'm not clear where the code is that's launching the thread, or for that matter why it's choosing the 'dummy' implementation. The Python docs suggest that 'alien' threads created through the C API would fall under this category. This suggests that either the PyWin32 ISAPI C code is launching the threads, or the ISAPI framework itself. Someone had mentioned needing to restrict the worker pool to a single thread but indicated they didn't know how to do that. I searched around MSDN and couldn't find anything relevant. I also checked the PyWin32 ISAPI code and didn't see anything that appeared to start a new thread. Does anyone know how to force single threading in this scenario? I've read some general stuff about ISAPI that all seems to say "your stuff must be thread safe." It looks like ISAPI is creating the threads. Unless I missed it I don't see anything in the Python-ISAPI source that is explicitly creating new threads for new requests. I'd prefer to avoid modifying the Python-ISAPI code but if I need to its no big deal. It looks like I could just throw a lock in there somewhere but I think that wouldn't prevent IIS from adding new threads. It would just force them to be handled sequentially. Ideally I'd like a way to flag the process as "busy" and not accept new threads, to force them to go to a different worker process for concurrent handling. And yes, I'm also investigating the possibility of making the app thread safe. But that's potentially a huge job. However if each new ISAPI thread got its own copy of modules, that would solve my problem except for any potential threading bugs in Python built-in modules. But I don't see any obvious way to enable that either. Has anyone looked into this issue before? many thanks, -Preston _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
