On 13/02/2015, at 10:37 PM, Paul Royik <[email protected]> wrote:
> Thanks will try now. > > But memory issue is still not resolved, right? Your existing code would never have actually stopped the running threads you were creating when the join timed out. That is what the timeout does for that. The threads would keep running, using memory as they go if the algorithm keeps creating more data it holds. Then when new requests came in, you would create more threads and compound the problem. So your old code would have growing memory usage because of that. Get rid of the usage of threads and use a simple time limit check embedded within the algorithm so it will exit. Just be careful how often you do the check. If your algorithm iterates, work out how many iterations might occur in 1 second and then have a counter for the number of iterations and check every so often the time when you have done a certain number of iterations. Then reset your iteration counter and keep going if time limit not exceeded until done enough iterations to check again etc. > Also, I found another time limit exapmple: > https://gist.github.com/Rabbit52/7449101 > > But I got 500 error on signal.signal(signal.SIGALRM, signal_handler) You can't use the signal approach in a multi thread application and you can't do it under mod_wsgi anyway as it blocks registration of signal handlers to ensure you don't screw up mod_wsgi's own use of threads to manage the process shutdown etc. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
