[python-win32] ISAPI and threading

[Preston Landers]

On Tue, Dec 1, 2009 at 5:33 AM, Mark Hammond <skippy.hammond at 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