On Sep 19, 2013, at 12:52 PM, Bin Huang <[email protected]> wrote:

> Thanks, Rich. What I did not fully understand before was that the tasklets 
> are all part of the one thread.

Hm. Tasklets are not precisely "all part of one thread" -- however (see below) 
they might as well be for
purposes of multi-core utilization.

> I just found the stackless SVN repository with talks and documents in google 
> code. Those are excellent resources for me to understand the stackless. And I 
> suggest putting a link to the SVN repository on www.stackless.com. Or maybe 
> not if www.stackless.com is depleted... 
> 
> Now my question is, how can stackless take advantage of multiple cores on my 
> machine since there is essentially only one thread?

The first question should be "how can *python* take advantage of multiple 
cores..."

The simple answer is that it cannot (at least in a single interpreter instance) 
-- except for a few  borderline cases for overlapped IO or non-python accessing 
extensions.
This is due to something called the Global Interpreter Lock (GIL) -- you can 
read a lot about this merely by searching google for "python gil" (more than we 
can, or should, say here).   

Since stackless is "layered" on Python, it inherits this behavior as a basic 
assumption.

> Tasklet is designed to reduce overhead but not for parallel hardware, right? 
> It seems natural to me to combine stackless with classic 'threading' and 
> 'multiprocessing' modules in Python, which is hinted by the examples in the 
> SVN repository. But I haven't found any document talking about this issue yet.

As you mention there are many methods for working around the basic problem, 
mostly involving
moving computation (perhaps by serializing/unserializing tasklets) into 
separate Python interpreter instances.
The difficulty is that the overhead of serialization may, in many use cases, 
simply overwhelm any performance
you would gain by core utilization.

> 
> Thanks.
> 
> 
> 
> On Wed, Sep 18, 2013 at 1:32 PM, Richard Tew <[email protected]> wrote:
> You have to run the scheduler to get tasklets to run and be switched
> between.  Remember that the tasklets are all part of the one thread
> they are running on.  So you need to run the thread, to run the
> tasklets.  If you use some external functionality to block the thread,
> then the thread is going to be... blocked.  It will not be able to run
> your code, which runs the scheduler.  nanosleep, whatever that is,
> obviously blocks the thread until it completes.
> 
> If you need to make a single tasklet sleep, then you need to write
> further logic to more intelligently run the scheduler.  Or you can
> install stacklesslib, which has implemented this functionality
> already.
> 
> 
> On 9/19/13, Bin Huang <[email protected]> wrote:
> > Hi list,
> >
> > I am working on a project that is based on stackless Python. I tried to
> > suspend the execution of a stackless tasklet from a Python C module
> > extension by calling nanosleep(). The Python C module that calls
> > nanosleep() is embedded inside the tasklet handler. However, my approach
> > does not work as I expected. It seems that the entire stackless interpreter
> > is suspended. And all tasklets had to delay (instead of sleeping) for the
> > interval time I assigned to nanosleep(). (I tried up to 10 second interval
> > so I could clearly see it).
> >
> > I also tried using sleep() in the Python C module extension and I observed
> > the same phenomenon.
> >
> > I know I could use stackless.schedule() to suspend a tasklet. But I am
> > still interested in why nanosleep() did not work in my experiment. Is it
> > because nanosleep() suspend the execution of the stackless scheduler?
> >
> > I can post my source code if needed. Thanks in advance.
> >
> > Bin
> >
> 
> _______________________________________________
> Stackless mailing list
> [email protected]
> http://www.stackless.com/mailman/listinfo/stackless
> 
> _______________________________________________
> Stackless mailing list
> [email protected]
> http://www.stackless.com/mailman/listinfo/stackless

_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless

Reply via email to