[Stackless] Google Summer of Code - PSF / Time is Short
Carlos Eduardo de Paula
carlosedp at gmail.com
Thu Mar 22 20:52:35 CET 2007
Regarding the considerations from Richard and Christian Tismer, they
are completely true, I didnt meant to have a dependency from stackless
from other modules like twisted. Of course having it all into the
stdlib (ok.. its stackless sdtlib) is a great way of making people be
attracted to stackless and not having to install a lot of stuff... the
misunderstanding here is that I expressed myself a little wrong..
since I dont have knowledge of socked and asyncore modules, when I
started doing network apps I jumped directly to twisted wagon.
On Andrew's point number 2, I agree completely with him,in the last
proposed examples, I guess more than 80% of the stackless+twisted use
cases have been covered.. the last blockOn function that has been
created based on Chris Armstrong and Greg Hazel's works.. which I
aggregated into one function (and added timeout feature) can be
applied to almost all deferred calls in twisted from tasklets.
I think the tasklet running the reactor and the t.i.task loopingcall
can handle it all, like Chris Armstrong proposed some time ago when
a member from the list was creating a reactor for stackless...
About the monkeypatching, I think that in a future, we can have a set
of modules that can integrate socket connections (already done),
fileIO, database wrappers and etc where they all wont block app
execution.. I think its going the right way..
I was looking at the monkeypatching code and found out that I'm not
prepared for coding like that.. the IOCP module does obscure stuff I
have no idea because it goes into the innings of the OS. I will stick
to the basic stuff, probably not in Google SoC, but the documentation
stuff interested me.. and I started to take a look in IDLE interpreter
to have an idea of how to create a interactive stackless
interpreter... (I liked it...)
On 3/22/07, Andrew Francis <andrewfr_ice at yahoo.com> wrote:
> Hello Richard and Colleagues:
> > Given my own non-use of Twisted and the level of
> >confusion that went on, on the list, in terms of how
> >to get Stackless and Twisted to best work together,
> how >the use of Twisted will affect people wanting to
> use the >monkeypatched facilities in the same manner..
> well, I >don't know the repercusions there.
> Two points.
> Although I would use a Stackless Python modified to
> use Twisted, I am increasingly of the opinion that it
> unnecessary to build Twisted support into Stackless.
> One can get much mileage from out-of-the-box Twisted.
> I would sooner contribute towards building a Stackless
> Python aware debugger....
> For the near future, I believe it more important to
> understand the issues about integrating Twisted with
> Stackless. For instant, based on Carlos's tests, I
> want to understand how adjusting the GIL improves
> performance. My own tests have shown that using a
> deque or uthread Queue provides modest performance
> boosts (the asynchrony helps). And like Carlos, I want
> to know why the threaded solution does not work if it
> is driven too fast after repeated invocations, that is
> running the executable two or three types in
> I will probably post again in the Twisted newsgroup.
> As for the different approaches. I believe a single
> threaded approach can handle 80% of the typical
> programmer's problems. I worked on a threaded approach
> because I have more esoteric needs (I have outlined
> those needs in previous posts). In turn, I had written
> tests where approaches using taskloop would break.
> Perhaps I was doing something wrong, but I have
> decided not to pursue that avenue. In turn, the
> threaded solution works, albeit with the provisos that
> were stated above.
> Again, I think if we share information and not operate
> in silos, stackless modules, monkeypatching, and
> Twisted approaches can all be improved.
> Now that's room service! Choose from over 150,000 hotels
> in 45,000 destinations on Yahoo! Travel to find your fit.
> Stackless mailing list
> Stackless at stackless.com
Stackless mailing list
Stackless at stackless.com
More information about the Stackless