On 07:56 am, [email protected] wrote:
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.
I disagree. The fact that a threadpool is used is part of the public
interface. The public WSGIResource class accepts a threadpool as an
argument to its initializer. The threadpool interface itself is public.
Basically, this is a parameter you're supposed to be passing in, and
you're supposed to have it configured in a way which is appropriate for
your application.
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.
I'd have a hard time deciding whether this is an improvement without
seeing an actual implementation. I'm not convinced it's necessary for
your use-case, though.
Jean-Paul
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
