Graham, thanks for this and the previous post. I've had these issues in
mind while designing the current bus, but you raised them far more
eloquently than I could have.
Graham Dumpleton wrote:
The only way we may know is to start stepping through specific uses
cases one at a time, not even
On Jun 26, 2007, at 1:04 AM, Graham Dumpleton wrote:
In Apache changing the certificates would need a complete restart of
everything. Because the child processes aren't privileged they would
not be able to trigger the main server to do so. This actually gets to
one of my reservations about
I've just made releases for Paste (core/Script/Deploy). Quick summary:
Paste core:
* The paste.httpserver has neat new threadpool stuff to improve the
reliability of your threaded server. Kill threads, see wedged threads,
restart the process, and more. This has been in progress for some time
[Graham Dumpleton]
First comment is about WSGI applications somehow themselves using
SIGTERM etc as triggers for things they want to do. For Apache at
least, allowing any part of a hosted Python application to register
its own signal handlers is a big no no. This is because Apache itself
On Jun 26, 2007, at 5:07 PM, Robert Brewer wrote:
I think I'm mostly confused by the name process bus because it
seems like the primary use case for something like this is where all
of the applications share the same process space
I don't see why it should be limited by that. The primary use
Phillip J. Eby wrote:
At 02:17 PM 6/25/2007 -0700, Robert Brewer wrote:
Phillip J. Eby wrote:
At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
For example, if an error occurs, isn't that an indication that the
component is broken? Masking the failure just makes it
less likely the
