[Web-SIG] WSGI thread affinity/interleaving

[Robert Brewer]

James Y Knight wrote:
> >> I'm worried about database access. Most DBAPI adapters have   
> >> threadsafety level 2: "Threads may share the module and   
> >> connections.". So with those, at least, it should be fine to move  
> >> a  connection between threads, since "share OK" implies "move  
> >> OK".  However, no documentation I've found has said anything  
> >> separately  about whether it's safe to _move_ a cursor between  
> >> threads. It seems  likely to me that it would not be safe, at  
> >> least in some database  adapters. And if it's not safe, 
> that means  
> >> a WSGI result iterator  cannot use any DBAPI cursor functionality  
> >> which seems a drag.
> 
> Okay, so I think the overall recommendation from DB-SIG is "don't do  
> that". I'm not sure where that leaves the WSGI discussion 
> now? "Don't  
> use databases from a result iterator", I guess (unless threadsafety  
> == 3)? But do anybody else's WSGI server implementations move apps  
> between threads? I don't especially want to make Twisted's be unique  
> in this way even if it is technically allowed, as I can only see it  
> causing problems when people's apps *do* try to use databases from  
> result iterators and *do* work everywhere else...

I have to admit that none of the apps, servers, or gateways I've worked
on have allowed for thread-moving or -sharing. I'm pretty well convinced
that CherryPy, for example, won't be able to support that anytime
soon--thread isolation is too well baked in.

Couldn't someone write a piece of WSGI middleware that takes requests
from an async server and dispatches them to a pool of Queues? The
consumer side of the Queue would then call the WSGI app with the same
thread each time for a given request, but the async-server side would be
free to create new requests and fetch results from different threads.
Sort of an async-to-threaded bridge. I would think, even if you chose
not to build that into your WSGI wrapper, that it would be generic
enough to be quite useful for any async server + threaded app. I'll
refrain from any predictions about performance, however... ;)


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org