Stackless/microthreads merge news

Armin Steinhoff Armin at
Tue Mar 14 09:19:47 CET 2000

In article <4jCy4.20737$W5.315338 at>, "Darrell" says...
>"Armin Steinhoff wrote:"
>> That's very interesting ... is there a way to get that implementation ??
>> We have ported Python 1.5.2 to QNX 4.25 and added a message passing module
>> to it.
>Here's a trick I used with QNX.
>Send a message to another task from an interpreter. The message contains the
>next step to run in the interpreter. The other task replys and unblocks the
>interpreter right away leaving the interpreter free to handle other
>requests. At some point the remote task completes and sends the word it was
>given back to the interpreter. So the interpreter picks up where it left

Interesting ... so you are doing real task switches.

>This kind of cooperative multitasking was nice for machine control. The time
>critical components were there own task. The interpreter only provided high
>level direction. It was easy to ensure the ordering of events. Normal
>threads  allow one thread to get ahead of another and require

Reply blocked messaging with a Python task as the core server could be also 

> Not bad if that's what you want as in the case of long
>calculations. For those cases start another interpreter, QNX will only load
>one copy of the code, so it's not as bad as it sounds.

It doesn't sound so badly ... the Python task takes just ~150K + 250K memory :-)

>Also since the interpreter was running in a remote box without monitor or
>keyboard, a terminal app helped a lot. It interfaced via these message
>snippets just like any other task.
>Many people can be logged into a single threaded interpreter and think they
>have it all to them self's. Like a web server with persistent state.
>The interpreter wasn't Python but could have been.

One interesting point is the speed of the message passing of QNX. 

It takes ~4us to transmit a message from a Python client to a C-coded server
task (K6/400Mhz). You can 'call' any system specific services (GUI, data base or
others) from a server tasks in order to extend the functionality of Python
_without_ changing Python for that purpose. The only neccessary change is the
implemention of the message passing functions (IPC)(done).

Micro kernel philosopy ->  Phyton is the kernel :-)



More information about the Python-list mailing list