Niphlod, let me tell you that the "0" is very often interpreted as "disabled" in computing. For example in "select()" the famous UNIX system call, uses that convention for the timeout argument and the "same" happens when you use the snapshop length = 0 argument in "tcpdump -s 0" which is allowed but certainly doesn't mean 0 length . It's not spectacularly wrong nor childish, it's just a common and useful convention. So, once I did not find this in the documentation, i tried that just as I tried timeout = None hoping to find it in use.
I understand where you are coming from but tbh i think at this stage it's too early for a scheduler engine to enforce that behaviour. There are scenarios where you don't expect applications to block but if that happens you might want to take different measures to analyse and handle what happened (while it is still running) and not necessarily to have them automatically killed. At the end of the day, a large timeout as you suggest, allows me to achieve the same result but actually doing so is what makes me feel a bit silly ;) Anyway, now I understand how it works, thank you. Kind regards, Francisco i did not find this on the documentation and On Sunday, 23 November 2014 19:20:52 UTC, Niphlod wrote: > > 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.
