thank you very much for the advices!
I asked myself many times, why not just use thread:D
After some research I found thread has some fatal defects
1. thread number is limited by os, that means the system don't want
you start many threads at the same time
2. thread pool is another approach for concurrent program, but the
context switching could be very costy
so here comes stackless way?
On Wed, Nov 12, 2008 at 12:10 AM, Aleksandar Radulovic <alex@a13x.netw rote:
I asked myself many times, why not just use thread:D
After some research I found thread has some fatal defects
1. thread number is limited by os, that means the system don't want
you start many threads at the same time
2. thread pool is another approach for concurrent program, but the
context switching could be very costy
so here comes stackless way?
On Wed, Nov 12, 2008 at 12:10 AM, Aleksandar Radulovic <alex@a13x.netw rote:
Hi there,
>
On Tue, Nov 11, 2008 at 5:57 AM, davy zhang <davyzhang@gmai l.comwrote:
>
Using stackless, every tasklet can have a channel which it uses to communicate
with other tasklets. The tasklet is blocked until there's something on
the channel
to receive.
>
>
You can have actors with many separate tasklets waiting for messages, still
being relatively lightweight, meaning you can run thousands of tasklets without
serious lack of performance.
>
>
This is cooperative scheduling, which you can choose not to use with Stackless
(instead, use preemptive scheduling). If you determine that one particular
task is taking too much cpu, you can declaratively call stackless.sched ule()
and put that task back to the scheduler queue and allow other tasks to
have a go.
>
>
That's right - with cooperative scheduling careful design is the key.
>
>
Stackless is an extremely lightweight way into concurrent programming.
I have personally used it in few projects and i quite like how lightweight
it is and how easy it is to write concurrent programs.
>
On the plus side, Stackless developers have plenty of examples and
common idioms of how Stackless should be used, which I highly recommend
you to check out. You might find a solution to your problem right there
amongst the examples.
>
>
Check it all out on http://www.stackless.com
>
--
a lex 13 x
--
>
>
On Tue, Nov 11, 2008 at 5:57 AM, davy zhang <davyzhang@gmai l.comwrote:
>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.
>the process function will handle the message as soon as the dispatcher
>object put the message in.
Using stackless, every tasklet can have a channel which it uses to communicate
with other tasklets. The tasklet is blocked until there's something on
the channel
to receive.
>
>This idea naturally leads me to place every actor in a separate thread
>waiting for msg
>waiting for msg
You can have actors with many separate tasklets waiting for messages, still
being relatively lightweight, meaning you can run thousands of tasklets without
serious lack of performance.
>
>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
>a tasklet blocked or do some time consuming calculation, the other
>tasklets can not get the cpu slice
This is cooperative scheduling, which you can choose not to use with Stackless
(instead, use preemptive scheduling). If you determine that one particular
task is taking too much cpu, you can declaratively call stackless.sched ule()
and put that task back to the scheduler queue and allow other tasks to
have a go.
>
>so we must design very carefully to avoid the big job for single task
That's right - with cooperative scheduling careful design is the key.
>
>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?
>concurrency program model or just I get a wrong idea to practice?
Stackless is an extremely lightweight way into concurrent programming.
I have personally used it in few projects and i quite like how lightweight
it is and how easy it is to write concurrent programs.
>
On the plus side, Stackless developers have plenty of examples and
common idioms of how Stackless should be used, which I highly recommend
you to check out. You might find a solution to your problem right there
amongst the examples.
>
>
Check it all out on http://www.stackless.com
>
--
a lex 13 x
--
>