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

[Alexandre Ferrieux]

Mark Hammond wrote:
> 
> > 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.

Yes but why emphasize the differences when you can instead wipe them out
by using MsgWaitForMultiple which integrates all sources ? Even if
there's
no message stream, it's fine !

> > > 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.

Yes, but see above: how would it hurt them to call MsgWait* instead of
Wait* ?

> > > 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.

Can you be more precise ? Which one(s) do(es)/n't fulfill the two
conditions mentioned earlier ? I do agree with the fact that the primary
msg loop of a random GUI package is a black box, however it must use one
of the IPC mechanisms provided by the OS. Unifying them is not uniformly
trivial (that's the point of this discussion), but since even on Windows
it is doable (MsgWait*), I fail to see by what magic a GUI package could
bypass its supervision.

> Ironically, Tk seems to be one of the worst for this.

Possibly. Personally I don't like Tk very much, at least from an
implementation standpoint. But precisely, the fact that the model
described so far can accomodate *even* Tk is a proof of generality !

> 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!!

As you said, all this is due to the assumptions made in Tk. Clearly a
mistake not to repeat, and also orthogonal to the issue of unifying IPC
mechanisms and the API to their multiplexing.

-Alex