Niphlod, i have no expectations whatsoever and specially when it comes to undocumented features but merely reasonable hopes.
Now, let me be clear here, I also don't expect software to be always properly documented and specially Open-Source where talented and busy people like yourself generously contribute to. I just mentioned it to explain my reasonable hope :) Thank you for adding some input validation in there, it is essential. Francisco > On 24 Nov 2014, at 09:00, Niphlod <niph...@gmail.com> wrote: > > 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 a topic in the Google > Groups "web2py-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/web2py/3GyfgbJzAio/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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.
