Python OS

[Richard Blackwood]

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).