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 request is now length(sending the email) - amount of the time the rest of the stuff you do before you join() takes, but if it's taking 30 seconds to send the email, you're still ultimately going to be taking a minimum of 30 seconds to serve that request.
Alex On Jan 4, 3:12 am, zvoase <crack...@gmail.com> wrote: > 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. Without asynchronicity, that time is going > to be spent by the interpreter doing nothing, meaning other > computations which might take some time and *could* be going on now, > aren't. So even though you're waiting for them all to complete at the > end, you're still saving time. Even if there was a simple decorator > which could be used, maybe it's a good idea to include that decorator > in Django; I could see it being useful to some people. > > Now on to Eric's comment: > > > 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. > > There is already at least one other web framework I know of (http:// > appcelerator.org/) which provides message queuing functionality as an > important part of the framework itself; I think that we're going to > start seeing a lot more of this sort of thing in web frameworks over > the next few years. Message passing is, as you say, a consideration > when trying to scale. I'm also not saying that Django should try to re- > implement something like Apache ActiveMQ, etc., but that a system > which tried to encapsulate some of these concepts wouldn't do the > framework any harm. > > > 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 asynchronous tasks would be killed as well, > > losing any tasks which hadn't yet been completed. > > To be honest, I hadn't thought about that; that indeed would make it > difficult to implement async signals. However, the aggregated 'join' > method could be called after the receivers have all finished, as > Apache will not terminate the Django process until all requests have > been handled; so there are probably ways around this. > > Also, I didn't know about engine, thanks for telling me about it. The > concept looks quite good, and I'm very intrigued to find out more > now... > > Thanks for your feedback so far. This is why I sent it to the mailing > list in the first place :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
