[Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

[Larry Hastings]

> As others have reported: if you have a gtk reactor and a wx reactor to 
> support, in addition to a "regular" Win32 reactor (e.g. PythonWin), 
> your approach still won't work. They all do GetMessage behind the 
> scenes (sp?), yet you would run them in multiple threads, so they get 
> their own messages. Plus they are not thread-safe.

I'm not sure what your point is here.  Let me see if I can clarify 
things, at least from my side.

I suggest it is possible to implement a PerfectReactor.  I define this 
PerfectReactor as a singleton top-level reactor which runs in the main 
thread of a Python application.   All incoming events would be 
serialized to this single reactor, which would dispatch them to their 
appropriate listeners.  When asked to monitor disparate event systems, 
the PerfectReactor would act as a concentrator of multiple other 
reactors, with various ugly things going on hidden in the 
implementation.  The goal would be that modular libraries of event 
listeners could be written in an agnostic manner, simply requesting to 
listen to whatever events they need to, and the main application 
wouldn't have to know in advance what reactors to configure or how to 
configure them.

You seem to assert it is not possible to implement such a 
PerfectReactor, and list counter-examples.  So far so good.

If you're saying "it is impossible for any implementation to 
simultaneously support more than one of the Win32, gtk, and wx 
reactors": fine, this hypothetical PerfectReactor can't do the 
impossible, but that's not an argument against a PerfectReactor.

If it *is* possible to support more than one of these simultaneously 
through precise configuration, I assert that a PerfectReactor could 
support that configuration too, and the goal would be to have it 
automatically configure itself.

You point out the gtk reactor and the wx reactor must be run in the main 
thread, because they run their own message pumps.  What I had in mind 
was that, when you asked to start listening to Win32 events, the Win32 
reactor would tell the PerfectReactor "I must be run in the main 
thread", and it would (re-) configure that to be the main thread's 
listener; the notification mechanism for other threads saying "there's a 
new event in your queue" would switch to using Win32 messages.  If the 
gtk and wx reactors had the same restriction, then whichever was first 
introduced to the PerfectReactor first would win, and introducing 
subsequent reactors would throw an exception.  (Again, can't do the 
impossible.)

However, if gtk and wx expose enough of the plumbing of their message 
pumps, this central Win32 message pump could identify messages intended 
for the gtk and wx reactor message pumps and inject them.  The gtk and 
wx reactors wouldn't call GetMessage, but they could call the rest of 
their message loops. Therefore they could all be run in the main thread.

(And yes, "behind the scenes" is correct.)

> if the PerfectReactor is to support Tcl/Tk, it needs to run the Tcl 
> even loop in the Tcl thread, which is normally the main thread (in 
> Tkinter, it's the thread where you originally created the tkapp 
> object). OTOH, PerfectReactor may also need to run some Win32 event 
> loop in the same thread.

Again, I'm not sure of your point.  If you're saying "it is impossible 
to run multithreaded Tcl and any message pump (Win32, gtk, wx) in the 
same application", then fine, PerfectReactor cannot do the impossible.  
If it is only possible to do with clever configuration, then I maintain 
a PerfectReactor could self-configure to support this configuration at 
runtime.

Cheers,


/larry/