durusmail: quixote-users: why pass request object to public functions / methods
why pass request object to public functions / methods
why pass request object to public functions / methods
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-05
2005-01-03
2005-01-03
why pass request object to public functions / methods
David Binger
2005-01-03
On Jan 3, 2005, at 9:32 AM, Zachery Corbiere wrote:
>
> The current implementation restricts you to a single publisher per
> process, and relies on that fact.  It makes it more difficult to
> implement different processing models - multiple simultaneous requests
> per thread, chaining one request across multiple threads, etc.  For
> example, I don't know much about Twisted, but I do know it's based on
> async IO, which means you can probably have multiple outstanding
> requests on the event processing thread.  How hard would it be to
> write an adapter to let you use Quixote 2 in that environment and not
> require a full return into Quixote on every request?  (I really don't
> know - it's not just a rhetorical question).

I *think* the shortest path to this multi-threaded publishing
capability is to
change publisher.py to maintain a _publisher dictionary mapping
thread ids to Publisher instances, to change the get_publisher()
implementation to lookup the publisher for this thread, and to change
all of the other get_* functions in publisher.py to call get_publisher()
instead of going directly to the global.  Not difficult to implement,
but perhaps difficult to test.

I seem to recall some quixote users (Titus Brown?) doing something like
this.

Personally, I would avoid publishing from multiple-threads whenever
possible.


reply