«

first here is my basic idea is every actor holds their own msg queue,
the process function will handle the message as soon as the dispatcher
object put the message in.

This idea naturally leads me to place every actor in a separate thread
waiting for msg

but the rumor has it, stackless python with tasklet and channel can do
much more better in concurrency program, so I dive my head into it.

but I found the tasklet is really a lined-up sequence , that means if
a tasklet blocked or do some time consuming calculation, the other
tasklets can not get the cpu slice

so we must design very carefully to avoid the big job for single task

I am just confused why the stackless python is said to be good at
concurrency program model or just I get a wrong idea to practice?

In article <mailman.3787.1226383071.3487.python->,
davy zhang <> wrote:
>
>first here is my basic idea is every actor holds their own msg queue,
>the process function will handle the message as soon as the dispatcher
>object put the message in.

Sounds like a standard design.

>This idea naturally leads me to place every actor in a separate thread
>waiting for msg
>
>but the rumor has it, stackless python with tasklet and channel can do
>much more better in concurrency program, so I dive my head into it.
>
>but I found the tasklet is really a lined-up sequence , that means if
>a tasklet blocked or do some time consuming calculation, the other
>tasklets can not get the cpu slice
>
>so we must design very carefully to avoid the big job for single task
>
>I am just confused why the stackless python is said to be good at
>concurrency program model or just I get a wrong idea to practice?

Well, you have to be a bit careful, but Stackless is definitely one good
approach to handling your design. For example, EVE Online is an MMORPG
written in Python with a similar design. That said, I personally have
trouble wrapping my brain around Stackless, so I'd probably choose a
different technique.
--
Aahz () <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan