there's a difference between "it's not documented" and "I expect it to do that" . In python standard lib, multiprocessing.Process join() method accepts a timeout, and that timeout argument can - theoretically - be 0. If you try that "outside" the scheduler, the same thing happens ... 100% cpu and erratic behaviour.
in standard lib, timeout=None means "let it run with no timeout", but the scheduler doesn't allow a timeout=None for the reasons explained before. summary: I'll send a patch to restrict the timeout value to be >= 1 instead of >= 0. On Sunday, November 23, 2014 10:29:19 PM UTC+1, Francisco Ribeiro wrote: > > 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.
