timeout gets passed as it is to the underlying base function. Python with timeout = 0 seems to exhibit a pretty strange behaviour, but I guess that is allowed just because in python "we're all consenting adults". Launching something that needs to return in 0 time is clearly something spectacularly wrong. As it is, scheduler is "bugged", in the sense that allowing a timeout=0 is not safe. Until now, all "consenting adults" never used it, and perhaps we should change the field to accept only integer starting from 1 rather than 0 (just to discourage "consenting childs" ;-P ).
As web2py enforces "good manners", there's no way to disable the timeout, and I think it's a safe decision to keep. A task queued with no timeout that can potentially block any other outstanding task in a task processor is plain silly. That being said, if you don't want any (theoretical) timeout, if you pass, e.g., timeout=999999, you'll get ~12 days of timeout. If your task is still running at that time, killing it is something that won't bother your application at all. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
