On Dec 17, 2005, at 5:25 PM, Phillip J. Eby wrote: > Yeah, that was the thing, I don't think we wanted to guarantee > thread affinity across yields, either in the sense of restricting a > thread for one app *or* an app to one thread. > > This does mean that iterator-based apps can't rely on thread-local > variables. I've recently written a "Contextual" library that > actually makes it easy for the task controller to manage this, by > swapping a thread's context in and out when you switch between > tasks, but of course it won't work for anything that doesn't use > Contextual variables. I originally proposed Contextual for the > stdlib in a pre-PEP, but Guido waved it off on the basis that PEPs > 342 and 343 aren't field-deployed yet and the usefulness is > unproven. WSGI, however, would be an example of a case where > contextual task-locals are needed even with today's Python, sans > PEPs 342 and 343.
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. Does anybody have practical experience with the safety of moving a DBAPI cursor between threads? James _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com