richardblackwood at cloudthunder.com
Sun Nov 7 18:28:27 CET 2004
Diez B. Roggisch wrote:
>>Are you so sure of this Peter? It certainly seems that this might be
>>possible but as you point out, if one uses Python for _time critical_
>>interrupts, the code will not live up to the _time critical_ aspect.
>>Indeed, I agree and never said otherwise. I could case less if it is
>>extremely slow as speed or even usability was not my aim (I never
>>indicated such either and in fact, I indicated otherwise by utilizing
>>such terms as _virtual_ and _prototype_ [As Jeremy bravely points out] ).
>I did not only mention the timing aspect, but also the GIL (Global
>Interpretor Lock) aspect of a python-coded interrupt routine. That renders
>python useless in such a case as it causes a deadlock.
I am ignorant in these respects, but deadlocks do not sound like a good
thing (contrary to what Martha would say).
>I've had my share of embedded programming on various cores with variying
>degrees of OS already available to me, as well as low-lever assembly
>hacking on old 68k-machines as the amiga. My feeble attempts on task
>schedulers and the like don't qualify as OS, but the teached me about the
>difficulties that arise when trying to cope with data structure integritiy
>in a totally asynchronous event like an interrupt.
>All that stuff has to be so low-level and carefully adjusted to timing
>requirements that python is ruled out there- sometimes even C doesn't make
>up for it.
Do you mean that there are no entirely C OSs?
>Thats what I had in mind when answering your question.
Understood, however, note the terms prototype and virtual. Perhaps I
could create virtual hardware where needed, and play around with the
timing issues in this manner (emulate them and create solutions
prototyped in Python).
More information about the Python-list