[Twisted-Python] Re: [Twisted-commits] r13446 - After a lengthy discussion, revert to previous threaded behavior wrt registering as the IO thread

[Glyph Lefkowitz]

James Y Knight wrote:

> So, the reasoning for re-breaking iterate() is that iterate is also
> broken in some other way, and thus it should remain broken in this
> regard too? How does that even make a bit of sense?

iterate() is broken as an API.  Without even going into the problems 
with implementing it on a proactor, how does one determine when to start 
and stop services in a reactor that we one is calling .iterate() on? 
What happens when you call .stop()?  .crash()?  Do we need to invent an 
external status API so that the .iterate()-caller is "on their honor" to 
stop running at the appropriate time?  Without sensible semantics for 
starting and stopping services, you can't start and stop the thread pool 
reliably, and, poof, you can't do anything useful with threads.  These 
are the least of our problems.

This is iterate() as an _external_ API.  Internally, .doIteration() 
makes perfect sense for most reactors.  The original use-case for 
.iterate() was to support screen-painting APIs, such as in a 3D game - 
perhaps reactors should instead have a 'callAsOftenAsPossible(callable)' 
method to support that instead.  (callLater is a bit too expensive, I 
think, and besides it doesn't work when the FPU is in single-precision 
mode, as it is when running within a process like DirectX or certain 
proprietary openGL drivers on Windows).  Another option is for such a 
graphically intensive application subclass one of the reactors and add a 
  frame-drawing hook in doIteration.

Does someone with a real use-case want to come forward? :)

> A better solution may be to get rid of all this mess, and just make
> it so that if the thread module is available, it is used. Forget the
>  "threaded mode" nonsense, and just make threaded-or-not something
> that has to be determined once, and finally, at startup.

The rationale for having this mess in the first place is that importing
the 'thread' module slows Python down by about 30%, even if you don't
actually run any threads.  Originally Twisted could run without
importing 'thread' at all even on a threaded platform - if we are going
to make the default resolver be threaded, then it's not clear how we
would restore that feature without leaving this mess intact and making
sure that installing the chosen resolver is done very early in the 
process's lifetime.

I'm open to other suggestions though.  I definitely don't like what 
we've got, and I don't think it works properly.