On Tue, Feb 2, 2010 at 11:13 PM, <[email protected]> wrote: > ... > Can you use a thread-local SQLite3 connection, or is that logic buried > too deeply in some other code?
It is, so this is not an option. > Another option (I think - untested) would be to give WSGIResource a > different implementation of the thread pool interface: > > class NotThreadPool: > def callInThread(self, f, *a, **kw): > f(*a, **kw) Well, that would work too but I think it isn't more elegant than my solution yet being shorter, as you still have to know how the _WSGIRequest's code works. A better option would be to delegate the threading strategy to subclasses of a generic "adapter" class which: 1 - Turns a Twisted Web request to a WSGI environment upon creation (i.e. in the __init__ method), adapts the input/output/error streams and so on. 2 - Let the class user start the WSGI application, whatever this means (start a thread or passing control straight to 3). 3 - Calls the WSGI application after starting to get the output from it. 4 - Writes the output the client. The adapter class provides 1 and 3. Since 2 and 4 deal with the threading/non threading strategy, they wouldn't be directly implemented by the adapter class: they are implemented in subclasses providing the wanted threading strategy. My two cents. Cristiano _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
