durusmail: quixote-users: Making Quixote work in a threaded Web server.
Making Quixote work in a threaded Web server.
2002-10-04
2002-10-04
2002-10-04
2002-10-04
2002-10-06
2002-10-07
2002-10-16
2002-10-16
2002-10-16
2002-10-16
2002-10-17
2002-10-17
2002-10-17
2002-10-16
2002-10-16
Making Quixote work in a threaded Web server.
Titus Brown
2002-10-06
-> > Err, I think this may be a misunderstanding.  Within my code, I keep the
-> > single publisher, and have multiple requests per publisher.  This is
-> > much simpler than having multiple publishers.  Subclassing works just
-> > fine...
->
-> Oh!  Well, you've actually *thought* about this problem.  I had blithely
-> assumed that one request per publisher, one publisher per thread was the
-> way to go.  If not, well, I've been wrong before.

Not only have I thought about it, I have a functioning piece of code that
stands up under stress testing!  (Next message.)

-> > I'll check out the current CVS and take a look at updating the patches.
->
-> Yes, please do.  I'm much more likely to actually look at a patch
-> relevent to current CVS.  ;-)

Attached is a patch that makes three changes minimally necessary to support
a model for one request/thread, multiple requests per publisher.

The patch is to publish.py in the current CVS, and the changes are:

1. start_time is now an instance variable of the request, not the publisher;

2. Publisher.try_publish now uses an accessor function 'set_request()' to
        set the request, and another accessor function 'clear_request()'
        to clear the request;

3. get_request and the associated module-level functions in publish.py (which
        are exported as 'quixote.get_request()' etc.) now use accessor
        functions on the publisher to get/set the request.

And, of course, the three functions 'get_', 'set_', and 'clear_'request() are
all implemented.

This code will behave identically to the current code, unless:

* someone is directly using quixote.publish._request in a subclass;

or

* someone is using Publisher.start_time in a subclass.

-> Also, I'm unlikely to hold up 0.5.1 for this.  Your patch will probably
-> make into 0.6.

Fine by me ;).  I don't see any reason -- the changes are not complex, and
can be visually confirmed to produce identical behavior to the current code --
but I'm simply happy that you might put 'em in!

In fact, when you check it in, let me know and I'll switch over to using
the pre-0.6 branch for my development work.

cheers,
--titus


reply