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 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
Hi Developers,
Basically, I wanted to ask for some devel's opinions on something.
When using the Django signals framework (which, by the way, is a very
good way of decoupling reusable apps whilst allowing for deep
integration), I sometimes find that a signal receiver does not need to
be called
10 matches
Mail list logo
