Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > "Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: > > Hendrik van Rooyen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
