with timeout(...):

[Hendrik van Rooyen]

 "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?
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...

- Hendrik