Re: December 15th - RSVP - Tornado with Gavin Roy

[paul santa clara <kesserich1@gmail.com>]

Thanks, Toby && Phillip.  The GIL problem similarly plagues ruby/eventmachine.  Is it company policy for you guys to team up and answer philly-lambda emails on your lunch break? ;)  Do you want to punch my nose?  Please don't.

-Paul 

On Tue, Dec 7, 2010 at 1:33 PM, Philip Fominykh <philip@glyf.org> wrote:

python is still limited by "global interpreter lock", so there's no
parallelism.

twisted uses "reactor pattern". their basic unit of computation is a
Maybe monad, which they call "deferred": it's an object with a
callback and errback closures. Every blocking function returns a
deferred immediately, you attach a callback to that deferred and
you're done. When there's a result the mainloop (the "reactor") calls
your deferred's callback. it's up to you to make sure that the
callback doesn't block and that it executes "reasonably fast". there
are various support classes for connecting deferreds together in
useful ways. it's essentially a monad, but without haskell's nice "do"
notation. naturally nobody groks it.

as far as i understand tornado is a reactor pattern with responders.
so you wire in handlers for events and make sure handlers don't
block/run fast.

in both cases the suggested solution for parallelism is to spawn
multiple instances. twisted has their "perspective broker" which is an
rpc that fits into their whole model, and if you're drinking deferred
kool aid makes things straightforward.

On Tue, Dec 7, 2010 at 12:28, paul santa clara <kesserich1@gmail.com> wrote:
> I have never played with twisted or tornado but what is the current state of
> their(and python's) support of kernel level preemptive mutlitasking?  Are
> they relying on green threads at the moment ala node js and if so, is it
> common to spin up multiple instances of an interpreter to achieve
> parallelism?
> Just curious,
> -Paul SC
>