nick at craig-wood.com
Wed Mar 28 11:30:03 CEST 2007
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
More information about the Python-list