[Python-Dev] Towards native fileevents in Python (Was Re: Python multiplexing is too hard)

[Mark Hammond]

> Other. Forget about sockets here, we're talking about true anonymous
> pipes, under 95 and NT. Since they are not waitable nor peekable,
> the only remaining option is to read in blocking mode from a dedicated
> thread. Then of course, this thread reports back to the main
> MsgWaitForMultiple with PostThreadMessage.

Or maybe just with SetEvent(), as the main thread may just be using
WaitForMultipleObjects() - it really depends on whether the app has a
message loop or not.

>
> > Is the mechanism different if it's a console app (vs GUI)?
>
> No. Why should it ?

Because it generally wont have a message loop.  This is also commonly true
for NT services - they only wait on settable objects and if they dont
create a window generally dont need a message loop.   However, it is
precisely these apps that the proposal offers the most benefits to.

> > I'd assume in a GUI, the fileevent-checker gets integrated with
> > the message pump.
>
> The converse: MsgWaitForMultiple integrates the thread's message queue
> which is a superset of the GUI's event stream.

But what happens when we dont own the message loop?  Eg, IDLE is based on
Tk, Pythonwin on MFC, wxPython on wxWindows, and so on.  Generally, the
primary message loops are coded in C/C++, and wont provide this level of
customization.

Ironically, Tk seems to be one of the worst for this.  For example, Guido
and I recently(ish) both added threading support to our respective IDEs.
MFC was quite simple to do, as it used a "standard" windows message loop.
From all accounts, Guido had quite a difficult time due to some of the
assumptions made in the message loop.  The other anecdote I have relates to
debugging.  The Pythonwin debugger is able to live happily under most other
GUI applications - eg, those written in VB, Delphi, etc.  Pythonwin creates
a new "standard" message loop under these apps, and generally things work
well.  However, Tkinter based apps remain un-debuggable using Pythonwin due
to the assumptions made by the message loop.  This is probably my most
oft-requested feature addition!!

So, IMO, I can't really see the point in defining a whole set of these
asynch primitives when none of the GUI frameworks in common use are likely
to be able to take advantage of them...

Mark.