[Python-ideas] PEP 3156 feedback

[Antoine Pitrou]

On Wed, 19 Dec 2012 08:55:02 -0800
Guido van Rossum <guido at python.org> wrote:
> On Wed, Dec 19, 2012 at 6:51 AM, Giampaolo Rodolà <g.rodola-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> > 2012/12/18 Guido van Rossum <guido-+ZN9ApsXKcEdnm+yROfE0A at public.gmane.org>
> >>
> >> On Tue, Dec 18, 2012 at 2:01 AM, Antoine Pitrou <solipsis-xNDA5Wrcr86sTnJN9+BGXg at public.gmane.org> wrote:> Event loop API
> >> > --------------
> >> >
> >> > I would like to say that I prefer Tornado's model: for each primitive
> >> > provided by Tornado, you can pass an explicit Loop instance which you
> >> > instantiated manually.
> >> > There is no module function or policy object hiding this mechanism:
> >> > it's simple, explicit and flexible (in other words: if you want a
> >> > per-thread event loop, just do it yourself using TLS :-)).
> >>
> >> It sounds though as if the explicit loop is optional, and still
> >> defaults to some global default loop?
> >>
> >> Having one global loop shared by multiple threads is iffy though. Only
> >> one thread should be *running* the loop, otherwise the loop can' be
> >> used as a mutual exclusion device. Worse, all primitives for adding
> >> and removing callbacks/handlers must be made threadsafe, and then
> >> basically the entire event loop becomes full of locks, which seems
> >> wrong to me.
> >
> > The basic idea is to have multiple threads/processes, each running its
> > own IO loop.
> 
> I understand that, and the Tulip implementation supports this. However
> different frameworks may have different policies (e.g. AFAIK Twisted
> only supports one reactor, period, and it is not threadsafe). I don't
> want to put requirements in the PEP that *require* compliant
> implementations to support the loop-per-thread model.

Why not let implementations raise NotImplementedError when they don't
want to support certain use cases?

> Read the description in the PEP of the event loop policy, or the
> default implementation in Tulip. It discourages user code from
> creating new event loops (since the framework may not support this)
> but does not prevent e.g. unit tests from creating a new loop for each
> test (even Twisted supports that).

Is it the plan that code written for an event loop will always work with
another one?
Will tulip offer more than the GCD of the other event loops?

Regards

Antoine.