> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4