On 2/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
>
> > *I* don't like the idea of something in the Python installation
> > deciding which reactor to use.
>
> I wouldn't mind if some way were provided of changing
> the reactor if you want. I'd just like to see a long
> term goal of making it unnecessary as far as possible.
>
> > In any case, your idea requires a lot of changes in external, non-Python
> > code -- PyGTK simply exposes the GTK mainloop, which couldn't care less
> > about Python's idea of a perfect event reactor model.
>
> On unix at least, I don't think it should be necessary
> to change gtk, only pygtk. If it can find out the file
> descriptor of the connection to the X server, it can
> plug that into the reactor, and then call
> gtk_main_iteration_do() whenever something comes in
> on it.
>
> A similar strategy ought to work for any X11-based
> toolkit that exposes a function to perform one
> iteration of its main loop.
>
> Mileage on other platforms may vary.
>
> > The PerfectReactor can be added later, all current reactors
> > aliased to it, and no one would have to change a single line
> > of code.
>
> Sure.
>
> The other side to all this is the client side, i.e. the
> code that installs event callbacks. At the moment there's
> no clear direction to take, so everyone makes their own
> choice -- some use asyncore, some use Twisted, some use
> the gtk event loop, some roll their own, etc.
There is no single PerfectReactor. There are several use cases where
you need to wait on >1 different event systems, which guarantees at
least two OS threads (and two event loops). In general it's nice to
have a single Python event loop ("the reactor") to act on said threads
(e.g. something just sitting on a mutex waiting for messages) but
waiting for IO to occur should *probably* happen on one or more
ancillary threads -- one per event system (e.g. select, GTK,
WaitForMultipleEvents, etc.)
-bob
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
