FAQ
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?

Search Discussions

  • James Mills at Nov 11, 2008 at 6:36 am

    On Tue, Nov 11, 2008 at 3:57 PM, 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.

    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?
    You could try circuits [1] - An event driven way
    to concurrency.

    --JamesMills

    [1] http://trac.softcircuit.com.au/circuits/

    --
    --
    -- "Problems are solved by method"
  • Davy zhang at Nov 11, 2008 at 7:45 am
    thanks very much for the hint, circuits is a very good event-driven
    frame work just like twisted

    but currently my project is in a pretty much complex way

    see, I'm designing a so called "Game Server", every client has their
    own task execution order, see like below:

    1.clientA wants to sale his armor
    2.clientA wants to buy the knife
    3.clientA wants to talk to npc

    I think for one client this sequence should be lined-up, the task
    should follow the 1,2,3step

    but there's multiple clients on this server so for multiple clients
    they can not wait until clientA finishing his job. if there's clientB
    like below:

    1.clientB wants to say something to npc
    2.clientB wants to attack clientC
    3.clientB wants to draw his sword

    the whole process for the server should be like this sequence:


    1.clientA wants to sale his armor
    2.clientB wants to say something to npc
    3.clientB wants to attack clientC
    4.clientA wants to buy the knife
    5.clientA wants to talk to npc
    6.clientB wants to draw his sword

    for clientA and clientB separately their tasks are lined-up, for whole
    system they are concurrent

    and plus I don't want to block the whole task system when a single
    client dealing with big chunk task.

    I don't know if I get picture right:)

    any idea about my design? thanks a lot
  • Aleksandar Radulovic at Nov 11, 2008 at 4:10 pm
    Hi there,
    On Tue, Nov 11, 2008 at 5:57 AM, 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.
    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
    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
    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.schedule()
    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?
    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
  • Davy zhang at Nov 13, 2008 at 3:28 am
    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 wrote:
    Hi there,
    On Tue, Nov 11, 2008 at 5:57 AM, 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.
    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
    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
    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.schedule()
    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?
    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
    http://www.a13x.info
    --
    http://mail.python.org/mailman/listinfo/python-list
  • Aahz at Nov 11, 2008 at 8:49 pm
    In article <mailman.3787.1226383071.3487.python-list at python.org>,
    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 (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedNov 11, '08 at 5:57a
activeNov 13, '08 at 3:28a
posts6
users4
websitepython.org

People

Translate

site design / logo © 2022 Grokbase