On 12:31 am, greg.ewing@canterbury.ac.nz wrote:

glyph@divmod.com wrote:

...

On 08:52 pm, theller@ctypes.org wrote:

...

When I last looked at twisted (that is several years ago), there were several reactors - win32reactor, wxreactor, maybe even more.

Only the very top-most level decides which reactor the application will use.

This is a worry, because it implies that there has to *be* a top level that knows what kind of reactor the whole application will use, and all parts of the application need to know that they will be getting their reactor from that top level.

The default reactor is the most portable one, 'select', and if no other reactor is installed, that's the one that will be used.

That may not be the case. For example, you want to incorporate some piece of event-driven code written by someone else into your gtk application. But it wasn't written with gtk in mind, so it doesn't know to use a gtkreactor, or how to get a reactor that it can use from your application.

"from twisted.internet import reactor" is the way you get at the reactor, regardless of which one is currently installed. There can only be one reactor active at any given time, because at the very bottom of the event-handling machinery _some_ platform multiplexing API must be called, and that is mostly what the reactor represents. The GTK reactor does not have its own API. It simply allows you to use GTK APIs as well, by back-ending to the glib mainloop. That is, in fact, the whole point of having a "reactor" API in the first place.

This is not my idea of what another poster called a "one-stop shop" -- a common API that different pieces of code can call independently without having to know about each other.

To my mind, there shouldn't be a "reactor" object exposed to the application at all. There should just be functions for setting up callbacks.

That's what the Twisted "reactor" object *is*, exactly. Functions (well, methods) for setting up callbacks.

The choice of implementation should be made somewhere deep inside the library, based on what platform is being used.

The "deep inside the library" decision is actually a policy decision made by a server's administrator, or dependent upon the GUI library being used if you need to interact with a GUI event loop. Perhaps the default selection could be better, but installing a reactor is literally one line of code, or a single command-line option to the "twistd" daemon. See: http://twistedmatrix.com/projects/core/documentation/howto/choosing-reactor.... It is completely transparent to the application, _unless_ the application wants to make use of platform-specific features. See the following for more information: http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf although technically Twisted's "reactor" is more like the slightly higher level POSA "proactor" pattern; asyncore is more like a true "reactor" in the sense discussed in that paper. Twisted exposes various APIs for "setting up callbacks" exactly as you describe: http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I... http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.I...

So at this point I'm skeptical that the Twisted API for these things should be adopted as-is

Given that your supporting arguments were almost exactly the opposite of the truth in every case, I think this conclusion should be re-examined :). If you're interested in how a normal Twisted application looks, see this tutorial: http://twistedmatrix.com/projects/core/documentation/howto/servers.html