Wow, sounds like you've taken a huge amount of work under your belt
(including naming only() and defer() :) ), thanks for all the hard
work! Can you give me a sense of what your solution for admin-urls
looks like, I just refreshed the patch on the ticket today, and the
last change I made(adding a
On Tue, 2008-12-30 at 08:43 -0800, Eric Holscher wrote:
[...]
> Also, does the major feature freeze mean that the features must be
> committed, or that they have have significant amounts of work done? (I
> don't see any of the "Must have"s for 1.1 having been committed..)
Quoting the Roadmap: "..
On Jan 5, 12:54 am, Malcolm Tredinnick
wrote:
> On Sun, 2009-01-04 at 06:19 -0800, zvoase wrote:
> > On Jan 4, 11:10 am, Graham Dumpleton
> > wrote:
> > > Not true, Apache doesn't necessarily wait for all current requests to
> > > complete before shutting down child worker processes. For a non
>
On Sun, 2009-01-04 at 06:19 -0800, zvoase wrote:
> On Jan 4, 11:10 am, Graham Dumpleton
> wrote:
> > Not true, Apache doesn't necessarily wait for all current requests to
> > complete before shutting down child worker processes. For a non
> > graceful restart or shutdown, Apache will give the pro
On Sat, 2009-01-03 at 08:25 -0800, rndblnch wrote:
[...]
> bump, bump :)
You appear to have accidentally bumped into your keyboard. You should
try to stop doing that; you'll hurt something.
We'll get to your patch in due course. If it solves your problem for
now, use it and be happy. That will s
On Jan 4, 11:10 am, Graham Dumpleton
wrote:
> Not true, Apache doesn't necessarily wait for all current requests to
> complete before shutting down child worker processes. For a non
> graceful restart or shutdown, Apache will give the process about 3-4
> seconds to exit and if it doesn't exit the
On Jan 4, 10:27 am, "alex.gay...@gmail.com"
wrote:
> Ok, but you're original concern was that what happens if say you go to
> send an email and "raises the issue that e-mail may take a while (i.e.
> from a few seconds to a couple of minutes) to send;", ultimately if
> you join on that thread than
On Jan 4, 8:12 pm, zvoase wrote:
> > For one simple example: what if Apache decides to kill or restart the
> > Django process
> > after a certain amount of requests have been processed (and I know
> > that many people have their servers set to do this)? The threads
> > which were are running
Ok, but you're original concern was that what happens if say you go to
send an email and "raises the issue that e-mail may take a while (i.e.
from a few seconds to a couple of minutes) to send;", ultimately if
you join on that thread than you've reduce the overhead insofar as the
new length of the
First, I'll address Alex's concerns. Basically, an async decorator
would work fine for some things, but it helps to be able to co-
ordinate the threads. Look at it this way; when something uses TCP,
for example, it's going to take a certain finite amount of time for
the TCP request to occur. Witho
If you ask me, a message queue sits quite firmly outside the realm of
what a web framework should be responsible for providing. I think you
are also underestimating the amount of effort and thought that goes
into writing a robust and scalable message queue. For one simple
example: what if Apache
I don't follow the argument against simply having the signal spawn a
thread. Why does the main thread ever need to regain control of it,
if the signal sender needs the response than ultimately the signal
can't occur asynchronously anyways, since sooner or later you'll need
to simply wait for the
12 matches
Mail list logo
