with timeout(...):

[Nick Craig-Wood]

Hendrik van Rooyen <mail at microcorp.co.za> wrote:
>   "Nick Craig-Wood" <nick at craig-wood.com> wrote:
> > Hendrik van Rooyen <mail at microcorp.co.za> wrote:
> > >  But would be useful to be able to do without messing with
> > >  threads and GUI and imports. 
> > >  Could be hard to implement as the interpreter would have 
> > >  to be assured of getting control back periodically, so a 
> > >  ticker interrupt routine is called for - begins to sound more 
> > >  like a kernel function to me.  
> > >  Isn't there something available that could be got at via ctypes?
> > 
> > I think if we aren't executing python bytecodes (ie are blocked in the
> > kernel or running in some C extension) then we shouldn't try to
> > interrupt.  It may be possible - under unix you'd send a signal -
> > which python would act upon next time it got control back to the
> > interpreter, but I don't think it would buy us anything except a whole
> > host of problems!
> 
>  Don't the bytecodes call underlying OS functions? - so is there not a case
>  where a particular bytecode could block, or all they all protected by
>  time outs?

I beleive the convention is when calling an OS function which might
block the global interpreter lock is dropped, thus allowing other
python bytecode to run.

>  Embedded code would handle this sort of thing by interrupting
>  anyway and trying to clear the mess up afterward - if the limit
>  switch does not appear after some elapsed time, while you are
>  moving the 100 ton mass, you should abort and alarm, regardless of
>  anything else...  And if the limit switch sits on a LAN device, the
>  OS timeouts could be wholly inappropriate...

Well, yes there are different levels of potential reliability with
different implementation strategies for each!


-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick