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.

Reply via email to