[Stackless] integrate stackless with other event driven framework: merge two

Richard Tew richard.m.tew at gmail.com
Sat Oct 14 20:36:38 CEST 2006

On 10/14/06, Jimsfba at aol.com <Jimsfba at aol.com> wrote:
> Richard, thank you for the comment. For CCP game's custom yielding approach,
> I got a question: when finish the work in stackless world and switching to
> another world (the other event driven framework, C++ watchdog for low level
> tcp/file io, etc), how long it want to stay there before switching back to
> stackless world ?
> - If the approach is "stay only when it has job to do", then when the two
> event driven frameworks are idle (no job to do), the code will be busy
> switching between the two frameworks again and again. It can cause a fast
> tight loop with up to 99% cpu usage.
> - If the approach is "always stay for x hundreds millisecond", then that "x
> hundreds millisecond" is wasted when framework we are waiting has no job for
> us to do.

This is something I wonder as well.  But it seems to me that this is a general
problem when you block for events, and not necessarily one which has
anything to do with Stackless especially.

Maybe someone else can chip in with what the standard approach is in
dealing with this?

> The wild guess that stackless internally (at system call level) is blocking
> at select()/ poll() call (after finish all callback jobs it need to do),
> because that's only way I can think of (in Unix part of implementation)
> which can listening/bockling on many different events queues without using a
> tight loop to scan all of them. If stackless use a different way to do it at
> unix system call level,  can someone shed some light with more info ?

When you talk about Stackless doing select and poll calls internally,
I am a bit confused.  Stackless does not itself have a need to do anything
like this.  It would only do it if you personally did it with your Python code.
All system calls done by it would be the same ones done by the Python
runtime itself (regardless of the Stackless modifications), and would be
the synchronous blocking versions which would block both your C++ code
and the Python code it invokes through running the watchdog.


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list